Very Sparkly (Evolving Thinking on GenAI)

Tired of my GenX references yet? No? Good, here is another one.

Let me explain. As you may notice from my more recent blog entries, "AI" is something I have been frequently thinking about. Especially trying to work through the hype, where GenAI is very sparkly and attention grabbing, to a place where I see how AI makes things better. Further, what is the intersection of my years of engineering and building AI solutions? Is there one? Take for instance this entry from a year ago where this journey started to gain traction for me. Or me thinking about Vibe coding back in July.

I’ve been thinking about what “engineering” even means now that anyone can spin up an LLM and build something that looks like it works. It’s too easy to confuse “the demo runs” with “the system works.” So here’s where I’ve landed - four realities that to consider. These are not my original work (thanks Nate), but landed in my conciseness at the exact right time.

1. If you can’t write the invariant, you haven’t engineered it.
This is the difference between vibe coding and engineering. “Make it work” is not the same as “define what working means.” AI gives you plausibility, not correctness. The invariant is what keeps you from gambling with probabilities and calling it architecture.

2. If you can’t measure it in production, you didn’t build it.
Anyone can make a demo now. Real engineering starts when actual users show up and start breaking things in creative ways. Observability isn’t a bonus -it’s the only way to know if the magic still works after it leaves the notebook.

3. If you can’t explain why it failed to a regulator, you haven’t owned it.
“The AI did it” won’t fly with the FDA, SEC, or anyone with a pulse. If you can’t walk a smart non-engineer through what went wrong, you don’t understand your own system. Ownership means accountability, not just implementation.

4. Good system design still matters.
Data is still the asset. Models are temporary. The LLM you love today will be obsolete in six months. Build so you can swap the engine without rebuilding the car. The fundamentals haven’t changed - only the excuses have. The data represents your value / asset, the LLM is a processor to help you realize the value of your data.

Bottom line: these form a lifecycle - specify, verify, and own. The tools changed. The responsibility didn’t.

 

A Brief History of Integrating

I was recently asked how I would integrate systems with similar functionality but different code bases and infrastructure. It got me thinking about how I feel I have been solving the integration problem throughout my career and how it (not surprisingly) keeps coming up. My answer was: It depends on what you have and where you want to land. I have many questions: how much of the data is the same? How reliable is the data? Is there an appetite to reduce any duplication? What is the desired recency (age) of the data? Is there a goal to become more homogenous? Regardless of the answers, I have employed several strategies/technologies over my career.

One of the first implementations I worked on was a practical solution for a PC-based application to leverage COBOL code on the mainframe. The company had invested years in the code and was not ready (or able) to rewrite it. We built an LU6.2 gateway to call the mainframe and pass data to the COBOL file's copybook. This was such a common need that later, Microsoft wrote an LU6.2 connector to create a code proxy from the copybook for you. Here we are 24 years after Y2K, and I am willing to bet that the banking and finance sectors still have a bunch of COBOL being used.

During the Object-Oriented boom, there was a big push to build an Enterprise Service Bus (ESB). We talked about technologies like MQSeries, CORBA, and RPC as ways to implement an ESB. I never saw an ESB I liked, probably because so many were never finished. Instead, I watched enterprise architects trying to resolve the enterprises' requirements into something for everyone. It's hard enough to nail this down for a single business line in an enterprise, much less many/all of them.

To some extent, we used databases as the point of integration. One system would be declared the data owner and copies of that data would be made for use by others. At the time, I saw this strategy fail more often than it succeeded because the copy would become stale and not meet our customer's expectations. Nowadays, we make copies, but it's less about integration and more about scale. To succeed, we had to figure out how to work in the world of eventual consistency.

As I shared these examples, I couldn't help but think of a few other topics. But these are the ones I wanted to share. If you've been in this industry for any time, I'm sure you have your own integration history. Integration is a persistent problem, a challenge that we all face, and it's safe to say that it's not going away anytime soon.

Do or do not. There is no try.

I recently dreamed I was in a large audience where an unidentified leader asked for a volunteer to lead a big project. They looked at me, and I said something like I will try, but I couldn't do it alone. Someone else stood up and said they would take on the project, and I could feel the audience staring at me with disdain. So much so that it woke me up.

I am not the type of person who looks for a lot of meaning in my dreams, mostly because I don't remember them. But this one woke me up, and I spent the rest of the early morning lying in bed, considering why it bothered me.

This was similar to talking to others and asking them how we get something done, and their answer is something like, "We don't have the resources." That wasn't the question; the question was, what would it take? My dream was similar because the question was not, "Would you deliver this project by yourself." It's not a question of ensuring a successful outcome; it's a question of pulling together enough for a reasonable discussion on feasibility.

The response I would guide my dream self to give is: Sure, I will lead that big project for you. Then, I would document what it's going to take to get it done and present that to the stakeholders. 

This dream bothered me because I was settling for trying when I knew better.

My Experience of APIs

I watched Nate Jones's TicTok last week. He talked about how APIs are becoming the interface to data. As I noodled on his words, I agreed with him, and it got me thinking about my history with APIs - more generally than his point.

I have been developing or calling APIs for a long time, and this got me thinking: weren't the MSDOS interrupts (related post) a form of API? We all know the right answer, so we will not say it out loud and move on.

But seriously. I remember creating an API for the DOS terminate and stay resident (TSR) module I wrote as the proxy for the server-based DBMS we wrote. This API used INT2F as the interface to the TSR.  We didn't expect CBASIC programmers to code to INT2F, so I had a callable C library that abstracted the internals. What we built was closer to something like ODBC, a generic API for retrieving data requiring you to write the query.

There was a period when our systems had a business layer and a data layer; the business layer represented business semantics, and the data layer represented the sproc/view/query/table structure. Weren't these all APIs? During the object-oriented period (which sounds like the Jurassic period), I didn't refer to them as APIs then; they were methods on an object.

We went from RPC to SOAP to REST, each an evolution to build distributed systems. All these are forms of APIs as well. Why? APIs are about creating a dependable contract that callers can depend on to create an outcome—not about the specific implementation technology. The "interesting" part of the API design process was how to design for reusability. And by interesting, I mean the part we spent a lot of time discussing. In the Enterprise IT space, we had enterprise architects who created taxonomies, libraries, and APIs that modeled the data and/or the business processes. Building models/services for the entire company didn't work, and a "single responsibility model" and "separation of concerns" were needed. Even now, we have engineers who have API design as a skill we depend on and use at some level of governance.

From these evolutions (and more) of APIs, I have learned they are hard. Why? Because API design is hard. Why? Because reuse is hard. This is why when we talk about APIs today, we don't think of them as static. Instead, we build them to be extensible as the needs evolve. Even designing for evolution, I have had more than my fair share of painful API deprecations.

I still love a good API design session.

Secure Apps Take a Village

I reflect on recent experiences and the tension between rolling out features and ensuring the product is secure. Features are flashy. They make good keynotes and/or demos. Features get customers excited and make money.

Security is about the backend. It's not flashy. It's hard to demo security; you probably wouldn't want to even if you could. But when something goes sideways, a security issue will lose you customers. It's like giving your competition bullets—"Hey, did you hear about that security breach at Acme?"

Security is getting more complex and more challenging to do well. Sure, we are smarter and better understand vulnerabilities. However, applications are also becoming more complicated (e.g., log4j and versioning). Complexity makes security harder—it just does. The bad actors are as determined as ever, and their methods continue to evolve.

I attribute much of this tension to the organization's culture. A typical culture pattern is when leadership compresses engineering estimates, and as time runs out, security verification takes place. This leads to pressure to complete verification and remedy errors without impacting the date. Regardless of the number of times that leaders tell people how important security is - actions speak louder. We must ship at this point in the project, leaving uncomfortable conversations and hard choices. 

The tension between shipping and being secure starts early, when most of the time is spent discussing/planning customer-facing features. Sure, security comes up, but in my experience, it gets a different in-depth consideration. If we are lucky,  the challenging security conversations/decisions are before we launch - and not after. Talking about security feels more like a bad thing when it's this late. Further contributing to this tension is when leaders push to make a date, a security issue is identified, and in response, they make statements akin to - "Security is always a priority, so when I push on the date, my expectation is that the system is still secure."

Imagine a product where this culture goes on for a long time; the product is very successful and lucky that lurking security issues are private. With some certainty, this culture will catch up with you, and a critical mass of security issues will arise, requiring engineering resources. Sometimes, the number and/or severity of the problems is so great - that feature delivery is paused, and most of the team is focused on remediation. I bet that for every case like this in the press, many more are not public.

Too often, I have seen teams rely on the hero model: people who, early on, take the risk of spending time on security—which, in my opinion, is under-acknowledged/appreciated. Or the heroes who scramble to fix issues after they are found—typically in a severe time crunch. The hero model is not sustainable and is unreliable for ensuring secure systems. Further, the hero model is often a symptom of something "wrong."

So, let's stop relying on heroes, best intentions, hollow statements, and punishing the bearers of bad news. In a fiercely competitive world, features are prioritized, and security often gets less attention, sometimes even becoming an afterthought. This is a culture war that needs to be waged. 

We must start by considering security not just as a necessity but as a feature as important as any other. We need to talk about it early. We need to do security reviews early and often. For instance, start a threat model on the first day, keep it up to date, and assess design decisions in the context of how it would change the threat model. Activities like this involve staffing security-oriented teams and embedding them into the project teams. Then, empower them to ensure positive security-oriented outcomes. A culture of security is independent of volunteers who take on additional responsibility to ensure a secure system.  We need mechanisms to help people do the "right" thing. Then, acknowledge (early) security wins, such as actions to avoid an event.

A culture of security is hard to change, and as leaders, we need to be honest with ourselves about it — are we backing up our words in ways that will lead to the outcome we want? Look in the mirror. Yes, the words mean something, but it takes more than words.

PS: If you're unfamiliar with the African phrase "it takes a village" - see here.

New Coding Problems = Old Coding Problems?

Late last year and into this year (2024) I needed to take time off to recover from surgery. As my mind started to clear but my body was still healing, I started poking around some code. At the time I was playing Pokémon Go (PG) and wanted to build my own mapping application. Well not actually from scratch but build it using a bunch of Python that others had assembled. I was not successful, and it the reason why got me thinking about libraries vs. binaries. 

Library vs. Binary reuse is one of those problems that has been around as long as I can remember. The first time I ran into it was when coding in C (pre-C++) and considering an #inlcude file (.h), a library (.LIB), or a dynamic link library (.DLL). I don't plan on rehashing that thinking now because we all know the right answer and so we can just move on.

The Python code / repositories I was trying to assemble for this purpose suffered greatly from the conflicting version problem. Where code in the same namespace was dependent on different versions of the same library. This creates a Gordian Knot of mixed versions that is very difficult to work out. I am no Python expert, but my understanding from those that are is that this can be a common thing in the world of Python.

Not to give Python a bad name, I know it would happen in Java too. Yes, there are ways to work around this, but I was more focused on getting the solution running that having to unravel dependency tree conflicts.

It was a walk down memory lane that got me thinking that a lot of the old problems I had as a developer are still around. I know the tools have gotten better at helping us manage these and lessen the pain of the problem, but the problem still exists.

Be a Student of Management

My experience is being a manager is hard. More specifically it's hard to do well. In my career I have tried being a manager and decided it was not for me and gone back to being an individual contributor. I liked the idea of being a manager but could tell I was not ready to be a good manager.

It wasn't until I became a manager where I was also considered an officer of the company and the company enrolled me in a year-long training. Oh wait, there is training for this? This is when I became a student of management. The assumption that the skills that made me a great individual contributor were the same as the ones I needed to be an equally great manager were quickly dispelled. I needed to grow some new muscles.

I am a naturally curious person, so this was something I wanted to learn more about. That is after I swallowed a little humility. I started off reading a handful of books recommended as part of the development program. These were helpful and gave me a foundation for the type of manager I wanted to be. But it was only through trying (and at times failing) that I learned where my weaknesses were. The biggest one was to not try and control the outcomes of using my technical expertise. This is where I came up with the pattern I called controlled failure - a topic for another post.

The key for me has been to acknowledge that as good of a manager I am, that I need to remain humble. There is always something new to learn. I have learned things at the best and worst of times. My goal is never stop learning how to be the best manager I can be - to always be a student.

Adam Grant is someone I have learned a bunch from. 

What do you call the people you write software for?

For most of my career I have referred to the people who I write software for "users".  It just made sense, they are using the software so they are users?

Interestingly enough at Amazon we call them customers.  Not to say that the word user has been stricken entirely from the vocabulary, but it makes me wonder if it should.  Here is my thinking.  Something different happens in my mind when I think of the people I am writing software for when I use the word customer.  It is hard to describe...but maybe this story will help you understand what I mean...

When I worked at Microsoft I worked in the consulting division and we would help people make sense of the variety of ways to write code on the Windows platform.  Often times some of my customers (aka clients) would have come up with a unique way to solve a problem using some piece of Microsoft software.  When I would relate this back to the product team (another aspect of my job).  More times than not the question I would get back would be "why would they do that - that is not what we intended".  We used to refer to this as the RDZ - reality distortion zone; which was the invisible field that hung over Redmond that prevented the product teams from understanding how people really used Microsoft product.

When I think about how a customer centric Microsoft would have been different - then the response back to me would have been something like "that is really cool, we never thought of that - how can we make it better".

Try it.  It may just change the way you think about things.

Firehose Treatment - Open Wide

I needed to take a short bit of time off from blogging while I worked out the details of interviewing, negotiating and relocating (at least me) to Seattle from Connecticut.  I am now into my second week of work at the largest online retailer and the fire hose is blasting full force.

Being this big means that someone has already done a lot of thinking about how to make something massively scalable.  Back in "the day" I remember pouring over the Principles of Transaction Programming book by Phil Bernstein.  I knew this stuff inside and out and it still serves me.

 

Given the massive need for scalability I have had to dust of some new/old theories. ACID is out BASE is in.  Sure I have read about a bunch of these over the last few years, but it is different being at a place that is actually doing it.

Here is a list of things blowing my mind today...

1. Eventual Consistency - It will get there when it gets there.


2. Anti Entropy - Anything with the word entropy in it I find confusing.  So what is Anti-Entropy? :-0


3. AWS - I had to pay for this before, now everything we deploy is already running on this.  Note to self; shutdown my services and save a couple bucks.

Keep It Simple (kiss) Revisited

I have a calendar from a vendor we use that has some of the classic coding and design principles - one for each month.  I was rubbing my chin staring at it this morning and I wanted to share what popped into my head...

While I am sure that the KISS principle has been written about (perhaps to death) I had another instance of this today as it applies to operations and infrastructure.

Quick background - I recently inherited an Operational group.  Operations is the clean up crew of development here.  While I understand the rationale of separating them, I think I like the idea of developers supporting their own code so that they better understand the impact of what they do.  What a great teaching tool - you want to not get up in the middle of the night - fix the code, do a better job in the first place, write a utility to help you out.  We have a bunch of applications that have been around for years and over time the developers who maintain many of these have moved on.  So today I asked the question of someone about two AD groups and what they are used for.  In both cases the answer was initially I don't know - and later the answer became these are not used anymore.

Part of keeping systems simple is getting rid of the things that are not used anymore.  We have all these extraneous moving parts that we don't need.  This just creates system bloat that should be easy to remove.

Granted you cannot get to everything - right now.  But this stuff has to get cleaned up over time.  Putting it into some sort of maintenance, wish list or Kaizen log seems like an easy thing to do.

All it takes is discipline.

IIS 7.5 and 2 Level Auth

We use a large vendor application at work.  We host all the infrastructure for the application inside the firewall, so there is absolutely no access from the Internet.

In IIS6 we configured 2 level authentication - NTLM and Forms Auth.  The vendor requires Forms Auth for the application.  Given the importance of this application and sensitive nature of the data; I also enabled NTLM and secured the site to only people in our division (about 450 people).  There are about 150 logins in the application meaning that 300 people have access to the site; even though they will not be able to actually see any screens until they login.

Through a series of discussions with different audiences; it was decided that there is still enough of a risk of those 300 people being infected with something that takes advantage of cross site scripting or other classic vulnerabilities.  So I further locked down the site using a more restrictive group.  While I feel like we are being a little paranoid about, I capitulated.

Enter IIS7...



Our standard for servers is Windows 2008r2 so we are on IIS7.5.  Doing this same 2 level authentication on IIS7.5 did not work.  Why?  Well because of the integrated pipeline...it simply cannot not do both at the "same time".  One has to come first.  In IIS 6 NTLM always came first since that was done my IIS and then Forms Auth since that was done by ASP.NET.

There are a couple of hacks out there that describe how to work around this.  One of which I found posted here by Mike Volodarsky (formally of the IIS team).  Here he talks about a way to make this work by splitting up the authentication and forcing one to happen before the other.  I was up until well after midnight last night trying to consider how I would make this work given that the application is a vendor application and I don't have the source code.  Not to mention that everything is precompiled, signed and obsuficated.  All of which add up to...this would be really hard to hack.

Finally, after a bit of chin rubbing...I came to the conclusion that the integrated pipeline may not be the problem at all.  Why do I even still need NTLM?  I mean if the only way for someone to access a web page on the site is to have a valid Forms Auth token then do I really need to force them to also have an NTLM token?  I went to bed content that I just need to leave NTLM behind in this case.

Now I just need to convince everyone that was pushing the original requirement for 2 level authentication that I don't need it anymore.  Being that they don't really understand the technology very well - that could be a challenge.  Since the way we got here was through a vulnerability scan of the web site in the first place - perhaps requesting another one will demonstrate my point and I won't have to make them understand the why.

I will post an update on the outcome.

Finally finished an entry from 2008...

Is Yukon Cornelius an Architect?

New OLEDB Provider for Reading Excel 2007

I work for a financial company that uses alot of Excel. Many of the the business users here practically live in it. So we are constantly trying to figure out how to leverage Excel in our applications.

Do we just export data to Excel? If so, then is it a snapshot/copy of the data or do we build a connection to the backend data? What about importing data? Where is the boundry between using VBA and VSTO? Then if we pile SharePoint and Excel Services on this heap it starts to get really interesting.

One of our technical frustrations has been the OLEDB driver for reading Excel on the server was fairly lame. It made alot of assumptions about the data that made it nearly unusable except in the simpliest cases. Last week I found this updated Provider for Excel 2007 and I am looking forward to giving it a deeper look. What I can say is, that it did read in all my data rather easily. I just have not had time to play around the fringes much.

Download details: 2007 Office System Driver: Data Connectivity Components
href="http://www.microsoft.com/downloads/details.aspx?FamilyID=7554F536-8C28-4598-9B72-EF94E038C891&displaylang=en

UI Testing

I spent a bunch of time in the early Windows days trying to do UI testing the way this (UI Test Automation Tools are Snake Oil) blog entry talks about. Like him (or his clients) we used some really expensive tools and ended up not doing a very good job. I really like the thinking Michael is doing here. This is definately where my head is at. The problem is that I am struggling with creating MVC-style applications.

Where I work now we just don't build big applications. Instead we have lots of small applications that we deliver in weeks not months or years. I have not found this pattern of doing software very condusive for building applications with lots of design. Now hold on a minute - that does not mean we don't do design. We just don't do lots of design. When an application is very small how much design do you really need to do? Most of the applications tend to look like each other - read some data...munge it together...display it. We don't do much data entry; which is an exception in the pattern of apps I have built over the years.

That is not to say we don't have some big-ish applications. We do. Just that they are the exception. Could they do with more engineering? Absolutely! But we just don't have the infrastructure (staff, mindshare, experience, etc) to do it that way. Of course there are people doing a high level of engineering here. It's just that it's not everyone - it's not our default.

At first this was a hard pill to swallow (and it still makes me a little gassy at times). But it's the nature/culture of the way we do things. It's a model that works, but not in a scaleable way. Sharing anything in this model is very hard - maybe I will blog later about how we do that.

Brick Wall - Bang Head

I had 17 (the number is not important except that it is more than one) Excel files I needed to get into a database and since wee happen to use SQL Server - I thought of SSIS. I was going to leave my trusty C# hammer in the tool bag for a more specialized tool. I was confident that even though I had not used SSIS for much (mostly trivial imports from SSMS) that I could get something running pretty quickly.

Well I could not have been more wrong.

I spent the entire day working through a series of SSIS issues specific to the problem I was trying to solve . The final issue was that a couple of the cells in Excel have more than 255 chars of data; what I nightmare trying to get the Excel driver to read more. And now that it is - its in an NTEXT data type which is practically useless when I really want a String. What a mess! Not to mention that I enlisted (wasted?) some help from other people (at least 4) who are much more knowledgeable on this technology than I.

The question I am asking myself is not whether to use a different tool (my trusty C# knife); but when I should have "cut bait and run"?

Every time I ran into an issue yesterday it felt like I was getting closer and closer to being done. Problem is that now feels like there was an infinate distance to travel; so closer being relative - i was never going to be done. At what point do I should I have realized this? Is one day too long to have been doing this? Is this just a case of arrogance and/or stuborness?

Just one of those things that makes me say Hmmmm.

It's hard to explain to people who don't do what I (we) do for a living this type of situation. I wonder how much time is spent / wasted doing just this sort of thing; using the wrong tool for the job. How many pople just keep banging a bent nail? Sure it works, but it's so britile you can never change it. I guess I could have just dropped a script component on the SSIS design surface and written the entire thing in C#. Too bad the debugger does not work. I am just too old to debug something using MessageBox.Show(). Geez! I am so anal about debuggers that a friend and I (he did most of the heavy lifting) wrote our own debugger for a Basic compiler we were using back in the early 90's!

I think I gave SSIS a fair chance. Now it's time to get this thing done.

What I am currently reading

...Pragmatic Thinking and Learning: Refactor Your Wetware

I am only 50% through. No code samples or object diagrams in this book. It's more about how to approach what I do as opposed to specifically how to do it. I like have been thinking more about this myself and am finding this book very interesting.

I liked the book by the same author (with others) called Pragmatic Programmer. Bernie turned me onto that book when it first came out and I recommend it highly. It's still as pertinent as the day it was written.

Web Application User Interface Paradigm

A Win is a Win

A win is a win is a close cousin to the win–win outcome. Recently at my place of work (which I cannot publicly identify here – suffice it to say its corporate America / Fortune 100) I had to compromise in order to achieve the high level goal and objectives; but not via the implementation originally planned. Just thought I would share this experience since it served as a profound reminder to me on the importance of meeting the goal/objective and not being too close to the implementation details. This is something I am personally struggling with lately as I find myself envisioning more and implementing less.

In this particular case it was around a code generator we have written to generate all the store procedures and data access code for .NET applications. For a number of reasons we ended up with two implementations that from a high level did the same thing. Each had features the other did not have. Since I am on the Architectural team I was really driving my implementation since it address more of the shared scenarios needed by the developers. The problem was that who was going to maintain this implementation? I could not, I have other fish to fry and need this initiative to be owned more by those who will be using it. It became apparent to me that this was just not going to happen; the reasons range from the “not grown here” mentality of developers to the general lack of understanding of what the tool did.

So in order to evolve the tool and to enable it to evolve; I had to make the hard decision to use the other code base. This was more of an ego thing than anything else. So once I was able to get over that the move was absolutely perfect. We are now going to have one of our top developers working on this key part of our development tools and I will be providing some high level guidance.

The reason this is not a win-win; even though it may seem so up until this point…We spent a bunch of money working on both of these tools. Most of the work on each tool was done by consultants; one who is very expensive and the other who is moderately expensive. Now I struggle with the age old problem of what happens when the consultant leaves or we decide we can't afford him anymore; which has already happened to one of the consultants.

What are you doing, right now?

I am having one of those ornery moments and I am taking it out on Outlook. It locked my machine up hard today and I don’t know why; which really burns my toast.

I was just scanning through the boatload of emails in Outlook 2007 and noticed an orange status bar continuously scanning on the To-Do Bar. Here is what starts running through my mind...

"I appreciate you showing me that something is happening; but can you throw me a bone...What the are you doing? Did you ever consider that maybe I want you to stop?"

So I set out to try and figure out what Outlook was doing; the way a non-developer may...

I tried hovering over the area – nothing.
I tried clicking – nothing.
I tried right clicking – nothing.
I asked the help system – nothing (don’t get me started).
I asked Google – nothing (could not form narrow enough query).

So what else can I do but to just rant on my blog about it. Wouldn’t you know it; I soon as I went to grab a screen shot – it stopped. So I took the screen shot anyway and circled the place where this happening. On the off chance that someone actually reads this AND they know what the heck that bar means; please let me know.

I think Microsoft has done a better job at reducing the number of pauses that happen in the software; where things just stop and have you wait for some “background” process to complete. It is my opinion (and we all know how many of these there are and what they’re worth) that it would be better to just tell the user what is going on; it’s the not knowing that makes it hard.

For instance, when I delete a file in Windows why does it take so long? What would be nice is if Windows told me in the status box…

"Please wait while I put this file in the recycle bin for you"
"Oh, this is taking longer than I expected because someone else is hogging up the disk channel"

[Note: Of course I hope that for the sake of my Mom that they would clean up the message a little; I can just imagine trying to explain that message to her (unlike Don Box's mom, my Mom does not know assembler).] Now that I know why I have to wait maybe there is something I can do about it – “Oh yeah, I started that Disk Cleanup utility a couple of minutes ago, maybe I should pause it”. Users will start to draw correlations between things and just become smarter.

Conceptually what I am describing sound nice; but as a software guy this pretty challenging. It seems like it requires design/architecture that supports the exchange of this type of information. Of course security would have to be honored. Not to mention that you may end up telling people more about the internals of what you are doing (or not doing) than you would like to. This would make a good thing to report on when capturing data around user experience, which Microsoft (and others) seem to be doing more of.

Sometimes I wish I was working on something this cool.