Software Lessons: The Customer is always right, and sometimes so are You

Here's one of my favorite memories from a project I worked on.

Our company had acquired another company and my team had the responsibility to integrate the new company's business into our system. There were some similarities between our existing business and the acquisition's business, but as there always are when companies merge, there were some critical differences too.

We worked really hard and managed to modify our system in ways that made the new company's work possible to do in our system. One minor feature they didn't ask for stands out in my memory. I added some auditing data to one of the screens we created for them. It would track simple things like when data was added or modified. I'd always found such things handy in support, so I did what I thought was the right thing and integrated it into the system in version 1, not as an afterthought hacked in two years later.

The analyst representing the acquisition noted in one of our design meetings that this was not a feature they needed or had asked for and why were we putting it in? I explained that it would be useful for ongoing support and that it would be done in a way that would not interfere with their work and that it would not negatively affect performance. The analyst still seemed a little bothered by this unasked for feature, but accepted it with my assurances. Note that by both some project management standards and agile development purists, this would have been considered a violation of the rules. In those worlds, I would have had to remove the feature (although it could arguably be a fair inclusion under what business analysts call a non-functional requirement).

Fast forward to about six weeks after the system went live. Things are going relatively well. The hard work in up-front design has mostly paid off and we had only couple notable bugs reported. Most either had workarounds or were fixed within the first post-implementation release. But then we get an interesting report from the same analyst that earlier had said there was no interest in the audit feature.

"We notice that the audit data doesn't seem to be working right. We expect the detail level items to be time stamped with the date of creation and they appear to be picking up the date of creation from the header level data instead."

I wanted to say, "Wait. Wow. Really? You are reporting a defect on a feature you told us you didn't want and wouldn't use?" But of course I said instead, "We can change that. We'll set up a change request and plan this for a future release."

Clearly, they'd been using the feature to see when data was created and/or modified and by whom. This is actually very useful reference information for both the support team and for the users. There are any number of situations where it's handy to know when and how something was changed, especially if that change is to foundational data that affects downstream processing. Unfortunately, not all systems track that information and many that do fail to make that information accessible.

The point here isn't to gloat that I was right. The point is that experience with support and systems can yield valid input into shaping subsequent systems. During design, there are many people of different experience levels and different personalities and perspectives trying to influence the product direction. Sometimes you, as the person that might live with the system after go-live, must find ways to get your ideas in place, even when traditional roles of expertise don't agree.

In theory, the International Institute of Business Analysis (IIBA) pays respects to the non-functional requirements, that is, requirements defined by the engineers. In reality, project managers and less worldly business analysts will overlook them in the interests of increasing project velocity. They don't have to support the beast for the next ten years, you do. So stand up for things that are reasonable and valuable for your team.

The customer is always right, and sometimes so are you.

Software Lessons: The Long Tail

One of the top misconceptions I've witnessed in IT work is that many view a software project as a discrete component. They assume that the costs are static and once a piece of software is in place, the costs end or are minimal. They will look at the cost to build and implement on Day 1 as the only cost.

This is so wrong that it befuddles me how often this mistake is made. The "long tail" of a system's life, comprising the care and maintenance of the application, is likely to be far more expensive than the cost of the initial implementation (assuming the software is useful enough to live for more than a few years).

This is especially true if the quality of the application is poor due to corner-cutting in the creation process (and given the common emphasis of deadline over quality, it happens a lot). This is why developers and project managers are often at odds. The project manager is working to a milestone and then moving to the next project, but the developer likely has to live with the completed product for a longer duration, suffering with that application's deficiencies. I've discussed this before, where such scenarios create soul-sucking and inspiration-sapping work that is menial and tactical in nature rather than strategic. Many of the people at the high end of these mistakes are not held accountable for these problems, due to the way the typical reward system's metrics work.

Change will require a major shift in metrics, and it must come from the top.