Well, there is a lot to talk about that software and the improvements we did. I will do so in other posts. In this post, I want to focus on the issue I see in every software maintenance projects - the status quo in keeping the software architecture intact, irrespective how much it changes in business functionality.
I frequently compare software to a car. The comparison arises in that both are built, run, need to be maintained, and tuned up. That's where the comparison ends. We don't keep adding functionalities to a car. We add bells and whistles like tint, color, alarm etc, but never add functionality or change it's function completely; we don't make a car run on square wheels or sideways. Though the engine gets hot, we don't use a it as a toaster or to cook chicken. But, in software we do exactly that.
When a custom software is designed or purchased, the users typically get all the functions they need. But, over the years users change and so does the business. We keep adding enhancements, bug fixes to the software constantly to meet the (sometimes unreasonable) business requirements that were never dreamed of, when we built the original software. The software thus gets bloated over a time period. We don't adjust the technical architecture or design to match this new software obesity and it eventually comes to a crawl, at which point everyone blames the software and want to replace it. By then, it may be too late! Many custom software out there have nice front ends, but - pardon my French - crappy code inside. It's like a flash new bus pulled by a mule, no offence to the mule!! I blame this on Software Status Quo! We tend to cater to business so much, we neglect the software itself in the process!!
Lot of this is due to the way companies budget for Software projects. Several departments tend to have a "lights-on" policy, which means keeping the software up and running 24X7 without any outage. Companies typically have a lot of budget for "operations" but not real software maintenance. As a consultant, I've seen IT departments struggle to define my work as part of "lights on", so they could continue to get funds for my contract.
Typically, the business side budget pays for the "operations". Except for a handful of savvy business managers, rest of them don't really understand software. To them, the "pretty" screens and "nice" reports are the software. As long as these happen, software is working fine. When you work with such managers, it is not easy to get budget for retrofitting software. "Business" requirements will always take precedence to technical requirements.
But, business is not entirely to blame for this. Recently, when I started introducing the changes in our software, I saw advantages of using more Java in a mostly Powerbuilder environment. There was some awe initially, then reluctance and finally an indifferent acceptance. New architecture means, new problems and tougher maintenance, at least initially. Now, I see why this status quo is continuing. I always hear senior programmers say, if it's not broken and/or users didn't want it, we wouldn't fix it. Where as, this is a safe approach to keep business happy, it hurts the software in the long run.
To end such status quo, business must stop treating software like stationary and recognize and allocate budget for it to be "tuned" regularly. I also feel, real end users (not just business managers) must be regularly consulted as to the performance and usage of the application. I've seen many a software projects fail, in spite of extensive design and funding, because end users simply rejected the software. Developers must also constantly look for ways to change and improve the software itself (not just it's business functionality) and strive to include these in their releases. I see several developers less motivated with the routine business fixes. Adding in technical items, may help to re-energize the developer base.
Many years ago, I worked in a warehouse in NJ where they were using an AS/400 for order tracking, but the software itself was so outdated, the users were improvising. Believe it or not, they would print a report out of this system, then they would input that information into System/36 along with accounting information and export to a file. The next smart user takes that to mainframe to finish up the final entry, where corporate wanted the original shipping and accounts information. Those systems people in Corporate, 3000 miles away conveniently ignored this status quo, that this process actually continued for many years until truly yours stepped in! Ironically, around the same time, corporate headquarters poured in millions to port some of their mainframe applications to flashy client/server tools.
I normally keep notes of all technical issues or a wish list for the software I work on. Then when I get to work on some business requirement in that software, I include any appropriate technical fix. Recently, while working on a business requirement involving Java stored procedures, I rewrote the logging mechanism completely, so we can support it better. Previously, developers were compiling and distributing this code to DBAs completely outside of the build process. If one class had to be updated, just compile it and patch it into the Jar file!!! This was error prone and I found some source code older than compiled code. I introduced eclipse and Ant to reduce human errors. Of course, it took longer to implement the task, but it pays for itself in the long run!
Oh yeah, we did solve the impasse at the warehouse in NJ, but it needed some thinking outside the box. I got the blessing from the local business director and with the help from users and corporate developers, we rolled the users to corporate mainframe (of course, after making necessary changes on the mainframe to accommodate them) and wheeled the AS/400 out, the one I was there to support in the first place! The company saved a bundle and everyone was happy!
No comments :
Post a Comment
I will be happy to hear your comments or suggestions about this post or this site in general.