Douglas Reilly has a great post on what seems to be a recurring theme throughout my career.  He talks about being tasked to write a system with features that he knows are fragile, implement it in such a way that maintenance and support costs are exponentially increased, and defend his position when he proposes what seems like a no-brainer fix to a problem that shouldn't even exist.  In summary:

“They are millionaires, I am not.“

This statement wraps up what seems to be a pervasive topic in the business applications industry in general.   A company's owners make the decision to implement a system to help reduce costs, increase revenue, and hopefully both at the same time.  This vision is passed to the management for implementation, who then forms a team of developers to implement.  Contractors and consultants are brought on with specific skills to round out the existing teams' skills, and there is no looking back from that point forward.  Do not question the goals of the project, you have deadlines.  Do not question a particular feature set, one of the owners says it is essential.  Before architecting the system, nobody thought to check to see if there was already a product that performs this task for them and if it fits their needs.

I have worked at several clients where I recognize within several minutes of talking with them about planned features for a system they are developing that their dream system is already implemented in BizTalk.  And I am not talking about stretching BizTalk to do some bizarre tasks that don't fit its purpose, I am talking about basic connected systems design. 

For example, one application needs to interface with a data entry clerk, perform basic validation, then queue the message through several different legacy systems depending on the message's contents.  This is a classic example of the EAI scenario that BizTalk solves through Orchestration.  Rather than look at BizTalk (it costs too much), they instead invested 18 man-years to develop a system that was fragile, impossibly complex to configure, and built around a concept of reusability that made the system anything but reusable.  The developers' joke about the system was that it was a brick house built with absolutely no mortar.  Sure, you can add a new wing onto your house pretty quickly, but doing so means you have to tear down the entire top portion of your home.  I heard that portions of that system are being re-evaluated for a face-lift using .NET and BizTalk

Another application needed only to process inbound purchase order messages from any one of 25 diffferent customers, each with a different input format and transport protocol, and convert the messages to a common purchase order format.  This is a glowing example of the B2B scenario for BizTalk where you configure different receive ports and channels, configure several orchestrations, and you are able to reuse the process again and again for newly added customers with little configuration.  Again, the argument against BizTalk was cost.  This time, I presented the case in a very strong manner, demonstrating through lots of neat charts how the projected costs for the custom solution (12 man years at an average of $50K per developer, or around $600,000) compared to that of a BizTalk solution (roughly $350,000).  This system was being written with VB6 around the time that .NET was first introduced in Beta, so I pointed out architectural limitations of their current architecture and how it would make moving to a new platform difficult.  They went with the custom solution.  Just a few short years later, they are now rewriting the same system with .NET and BizTalk.

This is not gloating, this is remorse.  Both customers are facing significant system rewrites with a tangible financial impact because they would not listen to the merits of using a product that was “not invented here.”  Of course, they would likely be looking at additional costs for upgrading to BizTalk 2004 in the near future since it absolutely rocks, but those costs should be dwarfed by the cost of rewriting a system from scratch to help solve some of the mysterious COM+ errors that suddenly appear in the Event Log without rhyme or reason.

How far should a consultant push a concept when they know they are right?  Do you risk alienating the project manager because a contractor proposed a system that would reduce his project time from 9 months to 2?  Do you risk alienating the architect(s) on the project because their system is notoriously fragile yet designed to some elusive requirements specification that nobody seems to remember exactly where the latest copy is?

Douglas quotes a cynical, yet realistic view from The Career Programmer:

I'm hired to write software, not to manage companies. Furthermore, if they want to pay me twice to write the same system, my bank makes little distinction when it comes to the deposits.

I see that simply keeping quiet and cashing checks is a definite option.  This keeps you employed as a consultant, and often the consultants who rock the boat the least are the ones with the greatest longevity on a project.  But why is there such little credit given to the career programmers who live and breathe technology enough to recommend solutions that will save hundreds of thousands of dollars?

In questioning the credence given to the developers, I am reminded of a recent post by Jim Fawcette about Wal-Marting of Software:

I argued that outsourcing software posed other risks, because it essentially exports and helps nurture competition in the one area that is a key, strategic advantage for the U.S. and, to a lesser degree, Europe. Software IP is the key differentiator for our economies, a technology whose impact is pervasive. From the human genome project to Pixar's movies, software is the core technology that makes it work.

This drew baffled looks. "Programming is a commodity, grunt work," said the board member. "Software isn't different from the textile industry," the CEO said.

I think Jim's post hits the nail on the head.  Software exists to increase revenue or decrease expenses.  The people implementing that software should be paid the least amount possible accorrding to the laws of supply and demand, and often business software is viewed as a necessary evil or expense center rather than as a profit center.  What many of the MBA types seem to forget from Management 101 in college is that investments depreciate in utility over time, and this effect is magnified for technological investments.  Further, the associated maintenance costs of technological investments often increase over time.  Make or buy decisions are often discussed right after Maslow's Hierarchy of Needs and Herzberg's Motivational Theory, so why is make or buy such an overlooked concept in the software industry?  Why is “not invented here syndrome“ so pervasive throughout the corporate world's IT centers?

This week's misinformed prroject management quote is actually one from several years ago:

“You say 12 man years like it will really take that long.  Remember, we have a deadline here.”