Memorial Day 2016: A war story that predicted the future of IT

I like traditional paper books and resisted going to ebooks. I like to think it wasn't because I was stupid, I certainly understood the value of their portability but I thought ebooks were soulless. I grew up in a time where a quality bound book was a piece of education and also a work of art. It was collectible and you could get an author to sign it. It had value. But eventually I succumbed to the lure of being able to have thousands of books on my phone.

I was slow to adopt audio books too, but recently started up after flooding in Houston caused my commute to become longer. And I've wiped out three books in six weeks or so, improving my rate of attacking my backlog.

One of those books was Day of Infamy, by Walter Lord. It was written a long time ago but is a detailed overview of the Dec 7, 1941 Japanese attack on Pearl Harbor. It's a great book. The Pearl Harbor attack was a surprise and a shock to many on the islands. Some people even mistook the inbound Japanese airplanes for Americans on training maneuvers.

When the servicemen understood what was going on, many moved to respond, trying to help others or pass the word. Many others tried to put up whatever resistance they could, even firing at passing planes with small arms. Getting those small arms was sometimes difficult. Lord's book mentions a couple situations relevant to this blog.

There were some instances where even amid the attack the supply clerks refused to issue arms or ammunition to the men without the proper authorization. This represents several of the themes I've noticed in our IT industry.

• Revering Process at the cost of Effectiveness. The intransigent supply clerks had a narrow focus on their role, which was essentially to control inventory. They lacked an appreciation for the larger picture and worshiped the traditions of their gods rather than the reality surrounding them. The impetus for this thinking may have been grounded in reasonable motives (cost control, safety, accountability) but such adherence to dogma rather than the primary goal of the institution (in the case of the US military, to defend the nation) may have cost lives. This anti-pattern is often the fallout of large organizations that have naturally segregated duties for specialization and formed silos of knowledge. These silos have their own management chains and can take a counterproductive focus as they work to justify their existence. This behavior doesn't require a large organization though; there are plenty of inexperienced managers out there that can do the same thing even in small companies.
• The Road to Hell is Paved with Good Intentions. I probably don't need to explain this one. In a world increasingly driven by people and groups that have mastered the ability to push personal interests over what's really important, you can find plenty of real world examples.
• The Tactical Reality will Override the Theoretical Ideal. Lord mentions that in some desperate cases, servicemen took axes to the locks on ammunition cages and did what they had to do. Yes, an accountant somewhere will be very hurt by the loss of the lock, but although Harlan Ellison astutely noted that "the world is becoming a cesspool of imbeciles," people are not completely stupid and sometimes humans can be surprisingly functional. Even though I can't stand the ludicrous edicts of the Sarbanes Oxley act, SOX procedures do allow for the people who can get the job done to have provisional authority in emergencies. But I'll bet money it wasn't Sarbanes or Oxley that allowed for that, but the grunts in the trenches that fought back against the original rules.

In honor of the servicemen that lost lives at Pearl Harbor that fateful day, I wish you a happy Memorial Day. 

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.

Shading rows for readability in a PowerBuilder datawindow

Just a little almost-useless tech note for myself.


I really like when developers do little things that make my life easier. Sometimes you'll see reports with a lot of data get shading to help your eye track the row you're reading.


I figured out a way to do this when I was doing a lot of PowerBuilder work. Apply an expression to the color property of the detail band of the datawindow. It's fairly easy to do if you just want to alternate every other row between two colors, but it gets trickier if you want to do it with more than odd or even rows.


Here's the code to shade every alternating set of three rows between light grey and white:

if ( mod(
          if( mod( getRow(), 3) <> 0
            , int(getRow() / 3)
            , int(getRow() / 3) - 1
            )
         , 2
         ) = 0
   , rgb(255, 255, 255)   //white
   , rgb(233, 233, 233)   //grey
   )

What this code is doing is using the modulus function to analyze the remainders of the row number divided by 3 to reduce it into one of two categories, grey or white.  In a division by three, the remainder would be 0, 1, or 2. If it's 1 or 2, we know it's the first or second row in a block of three rows. If it's a zero, we know it's a last row in a block of three rows.


But we want that third row to be included in the batch of three rows of a single color, and to alternate with every other set. So here's where the PowerBuilder INT function helps. We divide rows 1 and 2 by 3, and get a fraction, but the INT function simplifies them to the largest integer below the given value, so for rows 1 and 2, they INT function returns 0. But for row three we don't want it to fall into the next grouping so we subtract 1. Then we MOD these results by 2 to get the binary result of either a 0 or 1.


This makes our formula generate these values for the first several rows:


Row  Nested_IF  Outer_MOD
 1         0       0
 2         0       0
 3         0       0
 4         1       1
 5         1       1
 6         1       1
 7         2       0
 8         2       0


See how that works? It's fairly simple for the computer to process, but easily breaks each row down into either a 1 or a 0, and at that point it's pretty easy to wrap the whole thing in an IF statement and just assign the color.


I really only wrote this so I wouldn't forget it if I needed it again, but you're welcome to use it. If you're feeling "old school" you can use a light green instead of grey for the colored rows. And if you're a brainiac that figured out a way to do this with even less code, please post in the comments, I'd be happy to find an easier way.