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.

The Burning Ends Annual Memorial Day Post of 2013

It's become sort of a tradition that I post on Memorial Day. So here we are in 2013 and the cynical bastard is at it again.

American Sniper

I've just finished reading American Sniper [Amazon.com] by Chris Kyle. It's Kyle's memoir about his life as a US Navy SEAL. As SEAL biographies go, it about par for the course with plenty of action and anecdotes about the grueling training program and missions in Iraq. It's told with the help of professional writers and they do a good job of capturing Kyle's personality. Contrary to what some grunts probably believe about any of the special forces teams and their PR engines, Kyle is very reverent to other services, paying respects and recognizing they were truly a bigger part of the conflict than a few sniper teams. He is repeatedly humble about his achievements always felt like he was there to help others.

Kyle would have probably been proud to refer to himself as a Texas redneck, but there is something admirable about the no-nonsense common sense and honesty in this country boy's words. Kyle isn't shy about sharing his opinions and in this day of political correctness, I appreciate that even if I didn't agree with him on everything. Every day, and on Memorial Day especially, we honor our veterans by respecting free speech and free thought.

As I read the book, I found it echoed many of the themes I cover here at The Burning Ends. Kyle ranted about how administrative overhead could interfere with getting the actual job done. He dealt with a SOX-like regulation of his own where he had to document each shooting and have witnesses, and how sometimes those rules of engagement meant he had to refrain from sniping a questionable contact that might have gone on to harm other people. But Kyle wasn't stupid, he understood why those rules were there and even conceded that the recordkeeping had a benefit of helping him track his work.

The Decision-Consequence Gap goes to War

The book also reminded me often of my last post, The Decision-Consequence Gap. Careerist officer types more concerned with looking good on paper would withhold Kyle and his teams from working the dangerous zones where they could be more effective at helping troops. By being able to report low or no casualties the officer would look good. This is analogous to IT leaders that do not empower their teams to understand, master, and improve processes, hardware and software that will ultimately improve the business. In sports, that approach is often referred to as "playing not to lose" rather than "playing to win". I'll give the officers in question a bit more slack than Kyle does though, as human life is a harder chip to play than user comfort and efficiency or a little more profit.

The Cost

But there is always a cost for managerial complacency and selfishness. In Iraq, was the cost that more line troops lost lives without the overwatch duties Kyle's sniper teams could have provided?

That's an important point about cost. I wrote earlier about free speech and free thought and I do believe that how we carry ourselves and cherish the benefits of the American way is a measure of respect for veterans (recall Saving Private Ryan's [Amazon.com] admonition at the end of the film: people died for you to have this life. Make it worth it.). But Memorial Day is really about the cost, not the benefit.

So to every veteran, thank you. Again. We can't say it enough.

The Difference

And for you idiots that think all things military are bad, well, too bad. I know, there are Iraqi and Afghan citizens that call US soldiers the terrorists, and if someone lost a child to collateral damage from a drone-fired Hellfire missile, I sympathize for a pain that I wish no one would ever have to endure. But that goes for the children of 911 too, and I don't take kindly to being called a terrorist because there is a difference between us even with the mistakes we've made.

Kyle mentions Mike Monsoor, a SEAL that dove on a grenade to save his fellow teammates. It's not a one-time thing. There's also the story of Specialist Ross McGinnis who did a similar thing in Iraq to save others. THAT is the difference. For all our faults, Americans at large revere life. You don't hear stories about insurgents doing such things, they're too busy blowing up civilians. America reveres life enough to spend significantly more on soldier training and equipment. To spend significantly more on search and rescue operations. That is the difference; the enemy our military has been fighting for the last decade would do no such things even if they could. Kyle made no bones about calling the enemy plain evil, and as crude a description as it is, it is also the truth.

Chris Kyle, Rest in Peace

It is on a somber note that I close this post. I purchased the American Sniper as an eBook in early 2013. I later found that recently Kyle passed away [ABC News]. It was not from war, but from a tragic incident in which Kyle was trying to help another veteran. It's a terribly sad thing to happen after what Kyle endured in dealing with war and coping with the challenges of returning to civilian life and focusing on his family. But he tried to help others because he cared about life. And that's the difference that we should take from it.