Ok, ok - I’m not going to do the whole monologue, but you get the idea.  Where these processes exist, they’re likely deep in the stack of your enterprise, very possibly connecting you to partners you might not have been able to convince to move to your state-of-the-art real-time API backbone.  And when they break, impacts can be large.  Worse yet, if they fail silently or fail to process all the records they’re supposed to, the effects of these failures can go unnoticed for a while, and the resulting mess can be difficult to clean up.

Setting up the sample

As much as this article is about illustrating important processing guidelines and techniques, I’m also going to chronicle my use of AI tools to construct the example – showing prompts and responses for steps along the way.  I’ll start with repo creation, using ChatGPT for this one:

I want to create a repo to illustrate techniques to track inputs vs. outputs in batch operations, ensuring that no records are lost to errors or data leakage during processing. Suggest a suitable repo name.

I’ve stored prompts and responses in the accompanying github repo for many of these examples.  I’ll link them in so you can review details if you choose.  Following the naming prompt (I chose “batch-lineage-patterns” for the repo name), ChatGPT had some suggestions for next steps.  Again, the full responses are recorded in my repo.  Some of these are pretty good; others probably won’t fit with my intent for this illustration.

For the next step, I dropped into VS Code and began laying out an overall scenario to illustrate, asking copilot to generate a file to populate a Sqlite DB and another file to serve as the example file for updates:

Generate two files to illustrate a fictional scenario.  In this fictional scenario, an automotive parts retailer is going to receive a file from a supplier with car part inventory and pricing information.  Synthesize sample data to illustrate error handling in processing a batch update file.  Synthetic data needs to include the following:

• Sqlite data to simulate the master data of the retailer.  Fields should include partId, vendorName, partName, cost, availableQty, listPrice
• CSV update file from supplier.  Fields should include partId, vendorName, partName, supplierPrice, availableQty

The sample data set should include 100 rows in the CSV.  Of the 100 rows, 95 should be legally parsable (data valid per field names and data types).  Five rows should have bad data - an extra field, or a missing field, or an improperly escaped comma in a name field, for instance.  For the 95 rows that are parsable, 75 should map to parts found in the Sqlite master data.  The remaining 20 should be parts that aren’t found in the master file so that a lookup error occurs.

Generate a SQL file for the master data load suitable for use in this type of loading in application startup:
context.Database.ExecuteSqlRaw(sqlScript)

Also generate a CSV file to show the batch data update described above.

I saved the resulting files - they’re also in github.  My evaluation?  Not bad for a quick prompt, and in fact, the results are probably sufficient for the illustration I’ve got in mind.  Having seen the output, there’s room for some additional scenario specification, and for a more durable use case, I’d go back and reinvest in the specs.

Introducing Filehelpers

The batch-handling concepts here are technology-agnostic, but one package I’ve used with great success in the past will help illustrate some of the best practices I prefer.  Filehelpers.net is a nuget package that makes flat-file handling child’s play.  For this example, we’ll start with a simple CSV use case:

Following filehelpers quick start guide (https://www.filehelpers.net/quickstart/), create a mapping class for supplier_update.csv - call the class SupplierUpdate.cs.

The mapping class, as you can see, tracks cleanly to the fields in the CSV. Attributes allow formatting and validating fields on read and write - all very easy to extend if needed.

using FileHelpers;

namespace filehelpers_examples
{
    // mapping class generated based on supplier_update.csv
    // follows FileHelpers quick start conventions
    [DelimitedRecord(",")]
    [IgnoreFirst] // csv file contains a header row
    public class SupplierUpdate
    {
        // note: field names match header columns exactly (case-sensitive mapping not required)
        public int partId;
        public string? vendorName;
        public string? partName;
        public decimal supplierPrice;
        public int availableQty;
    }
}

To use the mapping class, just create an engine of that type:

using FileHelpers;
using filehelpers_examples;

var engine = new FileHelperEngine<SupplierUpdate>();
var result = engine.ReadFile("../../../supplier_update.csv")

If you run the sample at this point, you’ll see a ConvertException - something’s gone awry:

Exception has occurred: CLR/FileHelpers.ConvertException

An unhandled exception of type 'FileHelpers.ConvertException' occurred in FileHelpers.dll: 'Error Converting 'Many' to type: 'Decimal'. '

If you’ve worked with batch files, you’re no doubt familiar with this sort of exception.  Something’s not right somewhere in that hundred-row input file, but where?  Filehelpers can give us some help here:

var engine = new FileHelperEngine<SupplierUpdate>();
// Switch error mode on
engine.ErrorManager.ErrorMode = ErrorMode.SaveAndContinue;
var result = engine.ReadFile("../../../supplier_update.csv");
if (engine.ErrorManager.HasErrors)
    engine.ErrorManager.SaveErrors("../../../supplier_update.errors.out");

Now, when we run, not only are we able to load all the good records successfully, we also now have a file with real descriptions of the errors found:

FileHelpers - Errors Saved at Wednesday, March 4, 2026 7:26:49 PM

LineNumber | LineString |ErrorDescription

97|96,VendorA,"Bad,Name",23.00,20|SupplierUpdate|In the field 'supplierPrice': Error Converting 'Name"' to type: 'Decimal'.

98|97,VendorB,Too,Many,Fields,34.00,22,EXTRA|SupplierUpdate|In the field 'supplierPrice': Error Converting 'Many' to type: 'Decimal'.

99|98,VendorC,MissingPrice,,25|SupplierUpdate|Line: 99 Column: 25. No value found for the value type field: 'supplierPrice' Class: 'SupplierUpdate'.  -> You must use the [FieldNullValue] attribute because this is a value type and can't be null or use a Nullable Type instead of the current type.

100|99,VendorA,MissingField,44.00|SupplierUpdate|Line: 100 Column: 24. Delimiter ',' not found after field 'supplierPrice' (the record has less fields, the delimiter is wrong or the next field must be marked as optional).

 And, as you might expect, there’s support to read and parse the error file, as well, or to examine the errors at runtime.  In fact, setting a breakpoint after the read, we’ll see that between the engine and the result variables, we have all the information we need to ensure that all the records in the batch remain accounted-for.

Debug.WriteLine($"Read {engine.TotalRecords} records; {result.Length} successfully read, and {engine.ErrorManager.ErrorCount} errors");

Read 100 records; 96 successfully read, and 4 errors

This ultra-simple example illustrates some elementary, but often-overlooked principles of batch record processing.

Rule 1: Don’t lose records!

As shown here, always know how many records you take as inputs, and when you’re done, you must always be able to account for each record - be they successfully processed or not.

Rule 2: Explain what’s gone wrong.

One of the things that’s made me a fan of filehelpers is the information provided when errors occur.  Don’t make your users settle for anything less than knowing which records failed, and what’s gone wrong when failures occur.  Note how, in the error file above, we can see line numbers, the original input line, and a clear description of why the record could not be read.  These bits of information will make it quick and easy to find the offending record in the input file.  Of course, you don’t have to use filehelpers to do this, and the presentation doesn’t need to look the same, but please do not leave your users wondering what went wrong or where to find the problem.

Extending the sample

So far, our example is still trivially simple.  Let’s add another processing step – one more place for something to go wrong.  The point of this made-up scenario was to load a supplier update file and update inventory numbers, so now that we’re able to read the supplier file, let’s try to update the inventory values in our made-up master database.

A little refactoring supports creation of a Sqlite context, loaded at runtime from the values we asked copilot to generate earlier:

    this.Database.EnsureDeleted();
    this.Database.EnsureCreated();
    string sql = File.ReadAllText(filename);
    this.Database.ExecuteSqlRaw(sql);

I moved the filehelpers methods into a InventoryFileEngine class and created an IInventoryFileEngine interface to support testing.  A new InventoryUpdate class supports injection of the db context and file engine, and I extracted a results class to hold status from one operation to the next:

    struct BatchFileResult
    {
        public string DataFilePath { get; set; }
        public string ErrorFilePath { get; set; }
        public int TotalRecords { get; set; }
        public int RecordReadSuccessCount { get; set; }
        public int RecordReadErrorCount { get; set; }
        public int RecordUpdateSuccessCount { get; set; }
        public int RecordUpdateErrorCount { get; set; }
    }

With these changes in place, we can illustrate an update step that matches the part against our “master” data so that we could (presumably) update the inventory level for each part.  This lookup is trivially simple, and of course, we’d be very unlikely to look up the part based on part name, but I chose to work with the sample data generated by copilot, and I don’t think this diminishes the point of the sample.

        public BatchFileResult ApplyUpdates()
        {
            var result = _engine.Result;

            int successCount = 0;

            int updateFailureCount = 0;
            if (_engine.SupplierUpdateRecs != null)
            {
                foreach (var record in _engine.SupplierUpdateRecs)
                {
                    var partName = record.partName;
                    if (!string.IsNullOrEmpty(partName))
                    {
                        var foundPart = _context.FindPartByPartName(partName);
                        if (foundPart != null)
                        {
                            successCount++;
                        }
                        else
                        {
                            updateFailureCount++;
                        }
                    }
                }
                result.RecordUpdateSuccessCount = successCount;
                result.RecordUpdateFailureCount = updateFailureCount;
            }
            return result;
        }

The result structure now has enough information to track input records through both initial read and downstream update operations, and armed with this sort of data, we can create a sankey diagram in mermaid to show these results graphically.  Here’s the mermaid syntax:

config:
  sankey:
    showValues: true
---
sankey-beta

Read, Parsed, 96
Read, Parse-Error, 4
Parsed, Update Success, 80
Parsed, Update Failure, 16

And the resulting graph:

I love mermaid for applications like this because the syntax requires no graphics processing at all.  The resulting syntax drops right into wikis (including github, Confluence, and AZDO), or if you want to build them into an application, you can include the mermaid rendering JS in your app.

Advanced Considerations

Armed with a multi-step batch file processing example, as well as the ability to visualize results of processing, you can consider how you’d expect to handle problems when they arise.  In this fictional example, for instance, you’d want to understand whether it’s acceptable to process updates for just the parts considered successful here.  There may be cases where the entire batch needs to succeed or fail together.  In these cases, you’d need to reject a file like this as soon as you see any bad records at all so that a replacement file can be re-submitted.  

Options to reject and retry may be limited by the size of batches.  In some cases, pre-processing a batch of hundreds of thousands or millions of rows just to reject the batch is impractical and non-performant.  In these cases, an ability to output bad rows as a separate file (as shown earlier) can allow those records to be repaired and re-submitted.  

The techniques shown here can and should be modified, combined, and extended for specific applications.  The root principles (don’t lose records, and explain yourself) should remain, though.

Just as effective prompt engineering makes a big difference in the quality of output you can get from an LLM, the right guidance for Copilot will help it produce better work - especially in agent mode.  This article will focus on creation and use of Copilot-instructions to guide operation on a repo-by-repo basis, but before diving in, let’s review a few options in this ever-evolving area.

Instructing Copilot

The principle difference between prompt engineering and Copilot instructions is that prompt engineering tends to be transient and is certainly localized to your account-specific context. 

It’s true that Copilot Memory is attempting to fill this gap, and given emerging tools like OpenClaw, the transient nature of prompt engineering seems sure to disappear, but instructions that stick to you individually won’t maintain consistency in a team setting.

Enter Copilot-instructions, which let you save your project-wide Copilot instructions in a file that lives with your repo, visible to anyone who pulls your repo.  We’ll explore this option in depth shortly, but keep in mind this is not the only option to capture design and coding guidance for AI coding tools.

For guidance that can extend across multiple repositories, consider MCP integration with your project organization tool of choice.  Atlassian offers an MCP server for its cloud-hosted Jira and Confluence, and Microsoft has a similar MCP server for AZDO, as well as a Copilot connector.  Of these tools, the only one I’ve tried personally is the Atlassian MCP server, which operates mostly as-advertised.  Note that when used properly, the MCP integrations above can guide programming standards across all your code bases all at once, which is the stuff of dreams for enterprise architects - as long as these standards can be expressed efficiently and effectively.  It’s also worth pointing out that all these techniques can coexist, with Copilot-instructions operating in a bootstrapping manner to access enterprise-wide standards.

Getting Started

The basics for Copilot-instructions are as simple as could be - simply drop a file called Copilot-instructions.md in a .github folder in your repo.  Docs from github will go into detail on options like instructions that apply only to some paths or some agent LLMs.  This page also offers a prompt you can use to generate a Copilot-instructions file based on your existing repo, and that’s what we’ll try here.

For this example, I’m using a simple solution I created to explore vertical-slice architecture in dotnet Aspire.  You can find the “before” version of this repo here:  https://github.com/dlambert-personal/AspireTodo

For this demo, I’m going to use the prompt shown in the github docs verbatim.  I do believe that were I doing this in earnest, I’d want to customize the prompt somewhat.  I may also want to explore how this prompt works against repos of varying size, maturity, and cohesiveness. For instance, the bit where we ask Copilot to derive architectural elements of the project is especially interesting.  In a trivial example like this, I expect Copilot to find those elements quite effectively, but in a larger repo – one with some development history – I wouldn’t be surprised to see the model struggle a bit.  For reference, I’m using the Claude-Haiku 4.5 model in agent mode.

Reviewing the Results

So, how did the prompt do in its out-of-the box form?  Really not too bad; there’s some great content here.  My chief criticism (and one that’s easily corrected) is that I believe much of the generated content would do well migrated to the readme.md file, which I’ll do when I commit the “after” results to a new repo.  So, section-by-section, here’s what was produced.

• Repository Overview.  A good summation of the solution - probably better-suited to live in the readme.  All the information cited here is accurate and useful.
• Project Structure.  Definitely useful, and definitely a section I’d look to move to readme. In fact, I believe I’d replace this in the instructions file with an explicit instruction to keep this area current as the project evolves.  Along these lines, I’d like to see how Copilot handles the project as it grows in size. The level of detail shown in this section could grow unwieldy in a larger solution.
• Build & Development Workflow.  I found this section interesting.  It’s the first place I spotted an outright mistake (indicating that VS2022 would be able to work with .Net 10).  Beyond that, the instructions seem thorough and useful, including some startup alternatives that could prove helpful and database setup and migration instructions as well.  Once again, it’s possible much of this would be well-suited to live in the readme file.
• Architecture and Key Patterns.  An excellent section that summarizes design patterns and key integrations.  Again, frankly, one could argue this material could live in the readme.

• Common Tasks & Gotchas.  This section began to get a bit odd.  There’s a bit on adding a new API endpoint that’s pretty good, but there’s also a bit on debugging JSON deserialization that seems like pretty general debugging techniques I’d expect to uncover when needed in Ask mode.
• Known Issues & Workarounds.  This entire section suffers from the same problem - this entire section should be discoverable when needed and debugging topics shouldn’t be limited to the few topics presented in this section.

• Code Style & Conventions.  A short, but useful section - definitely one I’d keep in instructions and expand upon.  In my opinion, this is exactly the sort of guidance I’d want to see in Copilot-instructions.  Expanding on this area could help keep coding style consistent as the codebase evolves - one of the main objectives of Copilot-instructions in the first place.  If you begin orchestrating instructions across repos (using MCP connections to a wiki, for instance), conventions like this would be appropriate for enterprise-wide use.
• Troubleshooting Build Failures.  Back to material that should be general knowledge.
• Final Notes.  Another useful section I’d keep and expand upon.  The are specific instructions to the Copilot agent - again, exactly the instructions I’d want to see in this file.

Putting it to the test

Before I fine-tune the instructions, I wanted to test Copilot to see if it seemed any smarter with the addition of the initial draft.  I made a copy of the original repo (so you can see the “before” version) and asked Copilot (still using Claude 4.5) the following:

This solution needs to be refactored to account for a name change.  Replace all references to AspireTodo with AspireTickets.  Include solution name, project names, namespaces, component files, and variable names.  As always, the solution should build successfully when you're done.

Copilot plotted a six-step plan and got stuck on step 2:

This refactoring is extensive. Let me take a systematic approach:

1.    First, I'll gather all the source files that need namespace updates
2. Rename directories and projects
3.   Update all namespace declarations
4.    Update project references
5.    Verify the build succeeds

This is a problem I’ve seen frequently with Copilot: the powershell integration has a tendency to fail or freeze.  After closing the terminal, Copilot realized it needed another approach, and it tried again.  This went on for a while - the whole time showing success sprinkled with failure.  Had this been an actual developer, I’d have stopped them and suggested they revisit their plan, as it sure looks like a lot of guessing going on here.  The “stuck in powershell” problem continued as well – it seemed like Copilot expected powershell to understand commands that powershell just whiffed on - despite my installation being reasonably current.  

Finally, adding insult to injury, Copilot eventually just stopped working new tasks - apparently before it was done.  I gave it a little nudge, and sure enough - there was a little more work to do.

Finally - the build.  First attempt: five errors and two warnings.  All five errors were project files not found.  Copilot blamed them on Visual Studio’s cache, which seemed like a class-one cop-out. 

More confusion… more freezes.  Eventually, Copilot froze hard enough I couldn’t even cancel in the chat window, so I took matters into my own hands.  It turns out that aside from the file renaming issues, Copilot had gotten pretty close.  I had one “using” statement I needed to patch, and all the project files had to be removed and re-added, but once that was complete, I was back to building w/o errors again.

When all is said and done, did Copilot save me time in this refactor?  Maybe - but not by a ton.  I think the level of supervision is still quite high, but the remaining rough bits seem like they’re not so much a model shortcoming as an integration snafu - hopefully an easy update.

Next Challenge - adding to the UI

I suspected Copilot might do better with a change that didn’t require so many file manipulations, so I gave it a simple prompt that would require touching the solution in several places:

Modify the current page to be able add tickets in addition to displaying them.  Use the CreateTicket command in the API project to save the new ticket.

This request was dispatched quickly, and seems to have produced a high-quality output:

The project still built, and when I ran it, I saw a plausible-looking form.  The bad news: the form wasn’t submitting anything to the API, so I asked Copilot to fix it.  The resulting back & forth was almost comedic. I wasn’t about to let Copilot off the hook, and it did eventually figure it out.  I’d begun counting form submission attempts, and (if my count was right), it took well over two dozen stabs at this to get the form to submit successfully:

It could be argued that very little architectural guidance was provided to Copilot in the instructions we’d created, so the Blazor form submission stuff it struggled with might almost have been excusable.  I’m still a little disappointed here, though, because the real gotcha seems to have been an addition to .NET 10 (@rendermode) that was keeping the form from operating interactively, and the .NET version absolutely was covered in copilot-instructions.

For the last test / evaluation, I’m going to switch from Visual Studio 2026 to VS Code, and I’ll modify my prompt to specifically call out use of copilot-instructions, though I don’t believe this should be necessary.  This is the prompt used (including a typo on “architectural”):

Modify the solution to be able edit tickets that have been previously saved.  Use copilot-instructions.md as a reference to architecural norms in this solution.  Include UI changes to the Tickets page to load a ticket to the form for editing and submit changes to the API.  The API project will need a new EditTicket command to save the ticket.

I’ll be honest - I wasn’t expecting a drastic change in experience going from Visual Studio to VS Code, but wow, what a difference there was!  The initial change was quick, and as near as I can tell, perfectly functional.  I got an updated form that works as expected, the API adapter works, the API has been extended to include a new command, and the new command follows the design conventions in use by previous commands.  VS Code even asked me if I wanted it to test the new functionality, and that went slightly less-well – the spots where Copilot integrates to the world around it really do seem to be its Achilles heel right now.

Up to this last step, I believe I’d have given Copilot a barely-passing grade.  A co-worker from years back always used to remind me we don’t cheer for the dancing bear because it dances well – we cheer because bears aren’t supposed to dance at all, and this is about how I’d have summed up my experience with Copilot in Visual Studio.  Copilot in VS Code, on the other hand, seems much more well-sorted.

I’m still impressed with the amount of project documentation Copilot was able to sift out of my project, and I intend to press on with pulling some of the docs into readme and fine-tuning the bits that are left to be more prescriptive – in short, leaning on this a little more to get a feel for the edge cases.

In most cases, we accept “expected” where we find it and do our best to match it with “actual”.  This is an important part of usability writings like Don Noman’s “Design of Everyday Things” and Steve Krug’s “Don’t Make Me Think”, which help us understand how users have formed their expectations and how we can map software systems to those expectations.

I recently experienced an update from LinkedIn, however, that helped me appreciate how “expected” can be influenced.  On its surface, this update resembles others you may have seen - an email, perhaps, or an SMS you opted into a couple years ago, but this one struck me as just the right amount of notification in just the right place.

An important part of making this work is the channel in which this update is presented.  This update displayed right in the normal LinkedIn updates feed, which made it likely I’d see it, and also made it feel less spammy than a separate notification out of the blue.

It’s also possible that I appreciated this notification more because not a week prior to this, I had a UX experience that felt very different.  My experience began with an alert from my bank.  Had I just authorized a payment of [x] from Amazon?  I didn’t recognize the amount, and checked my Amazon account to see if this corresponded to any recent orders.  It didn’t, so I answered as such to my bank, and they immediately paused my card.  It was late, and I didn’t feel like finding out if my bank had extended hours support, so I decided to deal with it in the morning.  Of course, I forgot about it until lunch, when I reached for my card and remembered it wasn’t going to work.  A call to the bank was next, and the first thing they asked was whether I was a prime member, and might this be a renewal charge.  Sure enough - that was it.  Still no idea why it triggered the bank’s fraud algorithm, but the overall experience from soup to nuts felt crude and disrespectful - especially by comparison to the LinkedIn experience I saw later.

As always, the lesson here is best-applied broadly.  If you have an opportunity to form expectations anywhere in your UX, you’re far more likely to be able to meet them, and met expectations are gold in UX.

It turns out it was my fault (ultimately) the bot showed up in the meeting.  Last week, I’d attended a meeting where one of the hosts had invited this bot to take notes.   Following the meeting, the bot sent a meeting summary to all the attendees (so far, so good).  Having missed a specific point I wanted to look up, I tried accessing the meeting transcript, and was prompted to create an account.

What I hadn’t seen was the (in my opinion) extremely aggressive default behavior on the part of this platform to just go ahead and invite itself to any and all of my future meetings – even those in which I was a guest!

In hindsight, there are at least a couple of lessons to be learned from this experience.  First, as a consumer, all those damned EULAs actually matter.  Choose your connections with care, and consider the permissions you bestow on apps.  It may be a bit inconvenient to pass on an app that seems a bit greedy, but every once in a while, it just may save your bacon.

The other lesson is offered from the perspective of a product designer, and it requires a bit of empathy with respect to your user / audience.  Please consider - realistically - the behaviors your users might actually expect of your product.  In the case of this meeting note-taker, it’s appropriate to have the bot offer its services when I create meetings.  Ideally, I’d have liked to see something interactive the first time the bot has the opportunity to hop on a meeting, and if I elect, “yes”, I think it would be appropriate to ask if I want that to be the behavior for future meetings.  Offer a service to me, but don’t surprise me by joining behind my back!  

I also believe there should have been distinct behaviors for meetings I host vs. meetings I join as a guest.  In my opinion, it would be appropriate for the bot to ask to attend any meeting I join as a guest.  Finally, when joining, the behavior I saw in the meeting was very poorly-sequenced.  When the bot joined my meeting unexpectedly, it hung around for a good 30 seconds before offering anything in the chat window – a definite faux-pas.  I’d expect to immediately see a message indicating who invited the bot and offering actions to stop the recording if desired.  Having this message show up half-a-minute into the meeting is no bueno.

The era of AI is upon us.  Platforms can now do more for us than ever before, and what we’ve seen so far is just the beginning.  However, usability / UX practices need to be engaged for this journey so that these capabilities can be seen as helpful and not subversive or destructive.  Help you expect will always be welcome, but please beware helping in ways that aren’t expected - at best, this will be interpreted as “handling”, and at worst, it’s an unwelcome intrusion.  The first interactions you have with a new customer are precious - don’t botch them and risk losing a customer forever by overstepping your welcome!

Data changes over time

Let's break down the problem. I'm going to use tables / scenarios from Microsoft's ubiquitous Contoso model. This is fairly well-known, quite generic, and easy to obtain. In fact, if you're interested in downloading data sets in various sizes for these tables (and more), they're available here, and a tool that lets you generate sample data of your own can be found here (might be worth checking this out for generating test data for your own schema, too).

I'm going to focus on some hypothetical changes to the Product table. The Contoso tables are fairly well-engineered for "demo" applications, and the Product table is no different. This is a good baseline for what you'd expect to see in a table like this in a real application. The columns are pretty straightforward, and in this exercise, I'm going to focus on changes that might occur in cost or price over time. Some of these columns are really unlikely to change without resulting in a new sku.

In our imaginary data warehouse scenario, we'd like to be able to see changes in columns like cost, price, category, and so on over time. Perhaps we're interested in historic performance of products from different manufacturers, or fill in your own hypothetical, and since these changes over time aren't already present in the source data, we're going to show how to generate these rows using dbt.

In data warehousing, the visibility of changes like this over time is known as a slowly-changing-dimension (SCD), and there are a number of ways to model them. In this example, we're going to show type-2, which creates a new row when changes are detected. In order to do this sort of change detection, you'd need to be able to tell when a row has changed, implying the need for a row ID. Then, each field in the row would have to be compared to see if any of them have changed. Not sophisticated, but unwieldy. Luckily, dbt can do this for us with some simple declarative syntax.

dbt Snapshots

If you're building a data warehouse, there's a good chance you're already using dbt. This open-source tool is available in host-yourself form (dbt core) or as a SAS platform (dbt cloud). The example shown here is built for dbt core, and is available on github. This example uses a dbt seed to load the Contoso Product table - not the way you'd do this at scale, but it makes the demo more portable. Another nod to demo portability - we're using Postgres as our sample data warehouse. All the tools here are fairly agnostic with respect to database, so these techniques adapts to your tool of choice.

The dbt syntax to compute the type-2 SCD is called a snapshot. In our example, we name the output table (producthistory) and the source to be monitored (product). In the config section, note the strategy, which can be either "timestamp" if your source data has a last-updated-date column, or 'check', which evaluates values of columns. Also note the "check_cols" - the value of "all" here is quick and easy, but typically a list of specific columns is preferred for the same reasons we don't use "select *".

snapshots:
  - name: producthistory
    relation: ref('CDC_with_dbt', 'product')
    description:  Slow-changing dimension view of product
    config:
      database: cdcdemo
      strategy: check
      unique_key: ProductKey
      check_cols: all
      hard_deletes: invalidate 

Let's take a look at these snapshots in action. We're going to make changes to the following two rows (shown here in JSON to list fields as rows), and the highlighted columns:

{
"select * from dbt.product where productcode in (0101001, 0101002) \r\n": [
	{
		"productkey" : 1,
		"productcode" : 101001,
		"productname" : "Contoso 512MB MP3 Player E51 Silver",
		"manufacturer" : "Contoso, Ltd",
		"brand" : "Contoso",
		"color" : "Silver",
		"weightunit" : "ounces",
		"weight" : 4.8,
		"cost" : 6.62,
		"price" : 12.99,
		"categorykey" : 1,
		"categoryname" : "Audio",
		"subcategorykey" : 101,
		"subcategoryname" : "MP4&MP3"
	},
	{
		"productkey" : 2,
		"productcode" : 101002,
		"productname" : "Contoso 512MB MP3 Player E51 Blue",
		"manufacturer" : "Contoso, Ltd",
		"brand" : "Contoso",
		"color" : "Blue",
		"weightunit" : "ounces",
		"weight" : 4.1,
		"cost" : 6.62,
		"price" : 12.99,
		"categorykey" : 1,
		"categoryname" : "Audio",
		"subcategorykey" : 101,
		"subcategoryname" : "MP4&MP3"
	}
]}

When we update these fields and run dbt against the updated data, the producthistory table will now show four rows, corresponding to the two original rows and the updated version of each respective row:

{
"select * from dbt.producthistory where productcode in (0101001, 0101002) \r\n": [
	{
		"productkey" : 1,
		"productcode" : 101001,
		"productname" : "Contoso 512MB MP3 Player E51 Silver",
		"manufacturer" : "Contoso, Ltd",
		"brand" : "Contoso",
		"color" : "Silver",
		"weightunit" : "ounces",
		"weight" : 4.8,
		"cost" : 6.62,
		"price" : 12.99,
		"categorykey" : 1,
		"categoryname" : "Audio",
		"subcategorykey" : 101,
		"subcategoryname" : "MP4&MP3",
		"dbt_scd_id" : "daef36db7500c9e531447a11e0e3107a",
		"dbt_updated_at" : "2025-01-17T00:35:19.923Z",
		"dbt_valid_from" : "2025-01-17T00:35:19.923Z",
		"dbt_valid_to" : "2025-01-17T00:37:05.581Z"
	},
	{
		"productkey" : 2,
		"productcode" : 101002,
		"productname" : "Contoso 512MB MP3 Player E51 Blue",
		"manufacturer" : "Contoso, Ltd",
		"brand" : "Contoso",
		"color" : "Blue",
		"weightunit" : "ounces",
		"weight" : 4.1,
		"cost" : 6.62,
		"price" : 12.99,
		"categorykey" : 1,
		"categoryname" : "Audio",
		"subcategorykey" : 101,
		"subcategoryname" : "MP4&MP3",
		"dbt_scd_id" : "4b8654fbe0b5aad13f42ec52524dbe2b",
		"dbt_updated_at" : "2025-01-17T00:35:19.923Z",
		"dbt_valid_from" : "2025-01-17T00:35:19.923Z",
		"dbt_valid_to" : "2025-01-17T00:37:05.581Z"
	},
	{
		"productkey" : 1,
		"productcode" : 101001,
		"productname" : "Contoso 512MB MP3 Player E52 Silver",
		"manufacturer" : "Contoso, Ltd",
		"brand" : "Contoso",
		"color" : "Silver",
		"weightunit" : "ounces",
		"weight" : 4.8,
		"cost" : 6.62,
		"price" : 15.99,
		"categorykey" : 1,
		"categoryname" : "Audio",
		"subcategorykey" : 101,
		"subcategoryname" : "MP4&MP3",
		"dbt_scd_id" : "11d26c8c79e5e304ec85f86913a440b2",
		"dbt_updated_at" : "2025-01-17T00:37:05.581Z",
		"dbt_valid_from" : "2025-01-17T00:37:05.581Z",
		"dbt_valid_to" : null
	},
	{
		"productkey" : 2,
		"productcode" : 101002,
		"productname" : "Contoso 512MB MP3 Player E52 Blue",
		"manufacturer" : "Contoso, Ltd",
		"brand" : "Contoso",
		"color" : "Blue",
		"weightunit" : "ounces",
		"weight" : 4.1,
		"cost" : 6.62,
		"price" : 15.99,
		"categorykey" : 1,
		"categoryname" : "Audio",
		"subcategorykey" : 101,
		"subcategoryname" : "MP4&MP3",
		"dbt_scd_id" : "fd80b5a5d49a315dea7ca9f302065ec7",
		"dbt_updated_at" : "2025-01-17T00:37:05.581Z",
		"dbt_valid_from" : "2025-01-17T00:37:05.581Z",
		"dbt_valid_to" : null
	}
]}

Note the "dbt*" fields added to each record here:

• dbt_sct_id - a computed unique value based on the primary key and updated-at.
• dbt_updated_at - this is when dbt last touched this record. In our case, "touch" is alwasys going to be "add".
• dbt_valid_from - this is the beginng of the effective date window for each record. In the example above, note how dbt_valid_from is set to "now" when the model was initially built. If you need to adjust that value to synthetically backdate initial records to a datetime.min value, you'd need to do this in a subsequent update.
• dbt_valid_to - this is the end date for the effective date window. Note that for the current record, this value is left null to indicate no expiration date. It won't be set until / unless a new version of that record is created.

Limits of SCD

The example above is an illustration of synthesizing a type-2 SCD records in a worst-case scenario, and as such, it shows some of the pitfalls of this approach. The biggest issue, of course, is that the assignment of effective dates (begin and end) are tied directly to when (and how often) dbt is run. This can lead to some mis-aligned time-based relationships in the warehouse, as shown here:

If your source data happens to have a last-updated date, of course, you can use the "timestamp" strategy in dbt's snapshot configuration, which narrows the window for problems, but won't eliminate it. One of the keys here is to remember that this is a strategy for slowly-changing dimensions - the more active these data sets become, the more susceptible you are to errors.

If you need better accuracy for quickly-changing dimensions, consider modeling relationships in your transactional data. This is something you can see to an extent in the Sales table of the Contoso dataset, where prices and costs of products are saved right in the sales transaction. This captures the attributes that are subject to change in the Product dataset and are also of interest to Sales, reducing the need to link to a specific version of a Product. You can also use a near-realtime CDC tool like Fivetran, which is capable of monitoring source datasets for changes and triggering data events that can feed your warehouse with a much higher fidelity than the solution shown here. Any of these more accurate techniques come with a cost, though, so it's worth keeping this dbt option in your tool box.

So, I opened it up and began asking questions:

Are you able to analyze the page load requests of a web site and summarize calls to third-party web sites (with descriptions of those sites)?

And yes, it turns out, it was able to help. It asked me to upload a HAR file (with instructions about how to generate and save it in developer tools), and began to analyze per my request. I went back and forth a couple times, asking for clarification and tweaks, and after four or five rounds, ChatGPT let me know I'd used up my free analysis allocation.

But then, I noticed a little link the bot had been leaving for me, like a trail of breadcrumbs:

This link popped up a code block that contained the actual analysis for each step:

Going all the way back to the beginning of my chat, grabbing these steps, and dropping into a jupyter notebook, I found they ran almost as-is. Just a couple tweaks to the HAR file load locations were needed to make these scripts work in my local environment.

There are defintitely still adjustments you'd make when investigating specific challenges with / for specific web sites, but this experience demonstrates a few powerful principles:

1. Use of ChatGPT for analysis. This isn't news to most, but I was quite impressed by the speed with which ChatGPT made progress on this problem. With no code written on my part, ChatGPT made enough progress to help me understand more about my problem quite quickly.
2. Use of ChatGPT for code generation. Seeing the code generation popping out of the analysis steps without having specifically asked for it -- that was new to me, and a very pleasant surprise. Being fairly new to Python development, it was helpful to see this code as examples of the analysis techniques, including...
3. Use of HAR traces for website analysis. Seeing this chewed up by the example Python code was a helpful illustration of this technique.

If you're interested in seeing a jupyter notebook illustrating this example, you can find it here:
https://github.com/dlambert-personal/gpt_assisted_har_analysis

I believe there are clues all around us, though, that we can take advantage of if we pay attention. I'll begin with the premise / reminder that real usability is completely invisible. You can only see usability by the absence of impediments to usability. In short, a system is usable when it does exactly what a user expects, even if they can't articulate those expectations.

One of the best examples of invisible usability can be found in Visual Studio, which has been a market-leading IDE for decades now. Built by developers for developers, they've gotten a lot of things right, and even though you're probably not building a tool for use by developers, some of these lessons likely can apply for you, too.

Starting Fresh

Right off the bat, Visual Studio shows its usability by setting users up to be successful when working with a new project. Pick any template you like in Visual Studio, create a new project from it, and it will build successfully. While it might not seem like a big deal, it makes a lot of difference for a new user learning one of these technologies. The ability to start from a solid foundation gives that user confidence to build on that new solution.

What's the lesson? Be aware of the "getting started" experience for your users. Anything you can do to start a user more quickly and with more confidence will help them start using your software with confidence. When users get started with confidence and gain momentum, they're more likely to persevere a bit more if they get stuck later, too.

Save Always

Another subtle way Visual Studio helps is one you probably never gave a second thought. No matter what state your working files are in, you'll never mess one up so badly that Visual Studio won't let you save your work:

A more elegant take on this is to save automatically, so if something goes really wrong, you have a recovered version of your work (which Visual Studio obviously does). Note that automatically saving can actually introduce some small usability hiccups of its own, but that's a problem for another day.

What's the lesson? Document-based applications like Visual Studio and office apps (spreadsheets, docs and the like) typically consider this sort of behavior table stakes these days, and it's not likely you're building one of these, but watch out for behaviors that cause a user to not be able to save work-in-progress. In a UI, you may run into this if you've got a bunch of required fields on a page, and as the field count goes up (and maybe the page count, too), expect that your users' frustration level will go up, too.

It's actually a lot more likely that you'll run into this problem in your APIs. For example, here's a simple method I used in a post about fluent validation:

        public ActionResult CreateDealer(Dealer dealer)
        {
            Guard.Against.AgainstExpression<int>(id => id <= 0, dealer.Id, "Do not supply ID for new entity."); 

            var dvalidator = new DealerValidator();
            var result = dvalidator.Validate(dealer);
            if (result.IsValid)
            {
                _sampleData.Add(dealer);  // SaveChangesAsync() when working with an actual data store
                return CreatedAtAction(nameof(CreateDealer), new { id = dealer.Id }, dealer);
            }
            else
            {
                return BadRequest(result);
            }
        }

While this method effectively validates inputs, the return results to the user aren't especially helpful, and as an object like this scales up in size, it's more likely that a consumer will have partial inputs that don't pass all validation criteria. Rather than preventing this from saving altogether, consider structuring an object like this so that as many values as possible are optional for saving -- even if they're needed in order to have a "valid" object.

In this simple example, we can create a result type that appends a ValidationResult property to the model. We'll return this instead of the "naked" object to show the validation propertied next to the model. The result object is preferrable to embedding a ValidationResult in the model because this keeps the request intact -- there's no reason for the ValidationResult to be part of the CRUD requests.

    public class ModelValidationResult<M, V> where V : AbstractValidator<M>, new()
    {
        public ModelValidationResult(M model)
        {
            this.Model = model; 
        }
        public M Model { get; private set; }
        public FluentValidation.Results.ValidationResult ValidationResult { get; set; }
        public bool Validate()
        {
            V validator = new V();
            this.ValidationResult = validator.Validate(this.Model);
            return ValidationResult.IsValid;
        }
    }

With Validate in the Dealer object, the controller method also becomes a bit simpler:

         public ActionResult CreateDealer(Dealer dealer)
        {
            Guard.Against.AgainstExpression<int>(id => id <= 0, dealer.Id, "Do not supply ID for new entity.");

            ModelValidationResult<Dealer, DealerValidator> res = new ModelValidationResult<Dealer, DealerValidator>(dealer);
            res.Validate();
            _sampleData.Add(dealer);  // SaveChangesAsync() when working with an actual data store
            return CreatedAtAction(nameof(CreateDealer), new { id = dealer.Id }, res);
        }

Note that I left the guard clause in place here -- there will still be some validations that really need to prevent saving bad data, but now that these changes are in place, it's possible to save an object with incomplete data.

This technique won't work in all cases, but consider it if you can support saving objects with a minimal set of data and check for a fully-populated object later.

And more!

If you view Visual Studio with an eye to borrowing UX techniques, you'll see more lessons like these - the Dynamic Validation example I covered earlier is an example. Since you're probably not building an IDE or even a tool for developers, you'll need to interpret some of the techniques liberally, but I assure you the lessons are there. You may also see some negative usability examples -- in fact, sometimes these are easier to see because they get in our way and draw our attention.

If you're interested in source code for this examle, you can find it on Github: https://github.com/dlambert-personal/CarDealer/tree/Guard-vs-validate

Not much to look at by itself, but I've gotten a lot of mileage out of this in some useful contexts. You probably recognize one of the most obvious applications immediately: testing / QA. We're well-trained in applying expected == actual in testing, and most bug-reporting contexts will define a bug as a scenario in which actual behavior doesn't match expected behavior.

Even in this simplest application, all the value here is in how we exercise the framework, and I promise if you really work this equation, you'll have a better handle on bugs immediately. Of the two sides of this equation, "expected" usually seems easier, but is almost always more difficult becuase we most of our expectations are unspoken. If I had a dime for every bug report I've seen where "actual" was well-documented but "expected" existed only in the mind of the reporter, for instance, I'd be writing this from a beach in Hawaii.

Of course, that's where the exercise begins to get interesting. "What were you expecting" is a great place to start here. If you can trace expectations to real documented requirements, it's a short conversation (perhaps followed by another conversation to see why that scenario was missed in autometed testing). It's not unheard-of, though for these bugs to occur in scenarios that weren't explicitly called-out in requirements. If this is the case, be sure to examine "expected" to see if it's reasonable for most users to expect the same thing under those conditions, which is a great segue to my next favorite application of expected == actual.

I'm of the opinion that expected == actual is also a pretty good foundation for understanding usability. I touched on this recently in a post about API usability, and it holds true generally, I believe. In that post, I referenced Steve Krug's Don't Make Me Think, which is both an excellent book and another great oversimplification of UX. Both of these are built on the premise that whenever an application does what a user expects it to do, they don't have to think about it, and they consider it usable.

Mountains have been written about how to accomplish this, of course, and I'm not going to improve on the books that talk about those techniques, but as I pointed out with resepct to API usability, consistent behavior goes a long way. Even devices or applications we consider highly usable have a short learning curve, but one a user is invested in that curve, it's tremendously helpful to leverage that learning consistently -- no surprises!

A final consideration that applies in both these areas - when you find a case where "expected" really isn't well-definded yet, and can't be easily-derived based on other use cases (consistency), this is a golden opportunity. Rather than just taking their version of "expected" at face value, ask why they expected that (when possible). You probably won't be able to invest in a full "nine-why's" exercise, but keep that idea in mind. The more you understand about how those expectations formed, the more closesly you can emulate that thinking as you project other requirements.

Besides these examples, where else might you be able to apply "expected vs. actual"?

The near ubiquity of REST at this point can allow us to slip into some designs that I don't believe are particularly well-suited for this style of API. In this article, I'm going to briefly examine scenarios that work well in a RESTful style -- and why -- and for scenarios that aren't well-suited for REST, we'll look at some alternatives.

A closer look at REST

Most software developers will recognize a RESTful API, but for many, this is a "I'll know it when I see it" recognition. There's no shortage of defintions on the web for REST APIs, and I'd encourage you to browse a few to see what commonalities emerge. Among the most common traits are statelessness, cacheability, and most importantly, a resource-based interface.

The "resource-based interface" is key here - this is the bedrock of the "style" of a RESTful interface. Let's work through a simple example -- say, a car dealer web service. The GET methods here are predictable given a Dealer type:

Here, we've got a list of dealers and a GET for one dealer specified by ID. This is REST at its simplest. The resource here is the Dealer, and much of the fluency of REST comes from being able to predict not only how these APIs will work, but also the remainder of the major operations we'd expect. So, here, GET /Dealer will return a list of all Dealers known to this service, and GET /Dealer/{id} looks for just one.

Without even looking at the API spec, we know what most of the remaining operations should be for Dealers:

• Add - we expect to be able to add new dealers with a POST and a dealer model.
• Edit- we expect to POST to /Dealer/{id} with a dealer model to edit that entity.
• Delete - not all API's will support this, but for if this one does, it would be a DELETE action at /Dealer/{id}.
• Patch - again, where it's supported, it allows updates by specifying only fields that have changed, and again, we'd expect to find it at /Dealer/{id}.

A big theme contributing to the predictability of REST (which is one of the major appeals) is that you (the designer / developer) determine the resource - Dealer in this case - and the main operations shown here are largely implied. You design the noun, and REST supplies the verbs (they're even commonly referred to as HTTP verbs). Another way to look at these is to consider the resource as an object that's normally at rest (aka REST). Changes to this resource happen only when an HTTP verb acts on the resource.

The tendancy for these resources to change only when impacted by an HTTP verb via this API also contributes to the effectiveness of caching in a RESTful API, as you'll recall from the definitions referenced earlier.

Less universal, but very helpful, in my opinion, for a RESTful interface, is for the resource to behave atomically. Admittedly, the example we're using here is ultra-simplified, but when we act on a Dealer, the closer we can be to these guidelines, the easier it is for API consumers to predict how the API will perform (API's have usability, too!). These guidelines are based on the premise that REST is a web-native design, and developers will expect the API to behave as they'd expect other HTTP resources to behave.

• Operations are deterministic and cohesive. Ideally, each operation should stand on its own. Domain objects manipulated with these methods will certainly be subject to validation -- as in the url validation shown here. This is a local problem with the specific parameters sent on this call, and most API developers should have no trouble sorting out what they need to do to make this call work.
  
• Avoid "bell-ringing". A REST operation should be done when the status is returned to the caller. There will be cases where a changed resource will kick off a workflow, but monitor these carefully. If I kick off a workflow because I changed a resource and I don't care about the workflow, it may still be ok, but watch out for cases where a caller kicks off a workflow that they care about -- this may not be suitable for a simple REST-syntax method.
• Permissions apply to the whole resource. Imagine that the combination of resource and verb is all the information you've got to determine whether you're authorizing the operation. A user in a given role should ideally be able to create / edit / delete a resource or not.

Complications arise

As API operations become more complex, it's common to see use cases that bend the ideals of those simple REST operations. Many of these nuanced use cases can be shoehorned into a REST-like syntax. This is quite common for simple variations on verbs like Search or modifications or overloads of Add/POST or Edit/PUT. Watch for factors like these - they signal you're moving into API scenarios that require some special attention, and may be clues that you're not really working with RESTful methods anymore:

• Methods refer to a verb other than normal REST verbs. Some of these (ex: search) can be very compatible with a RESTful syntax and style. If you start running into bespoke verbs, consider switching to an RPC-like call. This can still live in the same API and use JSON for transport -- it's just going to be more verb-forward than noun-forward. These calls are invaluable as your API becomes more complex, but be aware that you give up some of the automatic usability of noun-based REST because these bespoke verbs are unique to your use case and application!
• Nouns begin to become complex. Consider a trivially-simple car dealer model:

        public int Id { get; set; }
        public string? Name { get; set; }
        public string? Description { get; set; }
        public string? Website {  get; set; }

This ultra-simple model works great in a RESTful API, but it clearly doesn't have enough detail to be useful. As soon as you add more detail / complexity -- in this case, an array of brand affiliations -- the model becomes more difficult to use in the API. This example works great in the domain model, but with the addition of one new BrandAffiliation collection, the JSON structure becomes much more difficult for an API user / developer:

  {
    "id": 3,
    "name": "Capital City Acura",
    "description": "desc",
    "website": null,
    "brandAffiliation": [
      {
        "parent": {
          "name": "Honda",
          "id": 3
        },
        "name": "Acura",
        "id": 1
      }
    ]
  }

A more friendly approach for the API user would likely be a nested REST structure that permits a get or post like /dealer/{dealerid}/parent/{parentid}. If this is starting to look like an OData style, that's great - that's a direction we'll explore more in the future!

Beyond Simple REST

In some cases, complex or complicated scenarios may be better-suited with an RPC-style method. These can live in a predominantly RESTful API - nothing about these is incompatible with the API specifications governing REST, but I think it's helpful to be aware when you're moving away from a pure REST model. Amazon has published a great summary of REST vs. RPC, and it's a great place to start in considering these styles. For our purposes, it's important to recognize that "RPC-like" in style does not imply an actual RPC API!

As use cases evolve beyond that simple REST/OData-like style we looked at earlier, here are some specific places where "simple REST" may not have enough gas in the tank:

• Verb-centric operations -- APIs where nouns participate, but operations are more about what's happening with those objects. These can be good places to explore those RPC-like calls.
• Operations tying multiple objects or object types together (likely in a non-heirarchical way). In some cases, graph-ql APIs can fall in this category.
• Anything that begins to take on state-machine characteristics -- I consider this a special form of verb-centric.
• Events. Depending on your use case and how deep you're diving into the event pool, these could wind up looking RPC-like or you may be interested in something like Async API.

In all these cases, be sure to be aware of discoverability and predictabilty of your API. In many cases, it can be worth shoehorning an operation into a noun-centric REST call for the sake of consistency. I'll explore some of these nuances in future posts, including places where CQRS meets events and API styles.

In the meantime, try paying attention to nouns & verbs in your API and see if that helps guide some decisions about API style.

But for much of this time, we've tuned in to software usability as experienced through our user interfaces by end-users. Today, there's more to usability than user interface design, and I'd like to broaden the discussion a bit.

Usability? What usability?

When you think about great user experiences, typically, we don't consider them to be great user experiences unless we start comparing them to lesser experiences. I believe this is a big clue into how we can apply UX more universally. I really think a lot of usability boils down to doing what a user is expecting you to do... so when you do it, most users will never even notice.

Think about it - when's the last time you gave a passing thought to usability for an application that was already behaving the way you wanted? There are scores of great books on how to achieve usability (I love Steve Krug's Don't Make Me Think, and Don Norman's The Design Of Everyday Things), but I really believe if you can manage to do what the user is expecting you to do, you're typically in pretty good shape.

The changing landscape of applications

Next, let's look at changes in applications and application design. You can probably see where this is going. Whereas once the only users of our applications were end-users operating via a Windows or web interface, cloud-native applications based on microservice architecture rely heavily on APIs to orchestrate, integrate and extend functionality. In many cases, APIs are the interfaces for services, and developers are our users. In this sense, APIs are the interface, and the user experience (UX) is found in the ease-of use of these APIs.

And what is it about an API we'd consider more usable? As with the generalized case above, I think the ultimate yardstick is whether the API behaves the way a developer would expect. I believe the popularity of RESTful APIs, for instance, isn't just because JSON is easy to work with -- it's because a well-written RESTful API is discoverable and predictable.

Note that discoverable isn't the same as documented - even correctly documented, which never happens. Discoverable starts with tools like swagger that expose live documentation of API methods and objects, but it connects with predicatable in an important way: as developers engage with your API and discover how some of it works, consistent behavior and naming creates predicability. When these two factors are combined, they reinforce one another and create an upward spiral for developers in which learning is rewarded and also helps future productivity. And yes - this exact relationship is part of understanding usability in a visual / UX context, as well.

Watch for more posts on API conventions and style soon, and watch for the ways these ideas support one another and ultimately contribute to Krug's tagline: Don't make me think!