Building Bridges to Nowhere

I had to deviate from writing my originally intended post for today about migrating from Teradata and Business Objects to SQL Server 2005, because someone needs to remind Ms. Davidson @ Oracle that developers are not building bridges. Now, I agree with her mindset in principle, but she seems so caught up in the less-than-useful construction analogy that she's laying all the blame at the wrong feet, IMNSHO. I will grant that there have been/are people with a title synonymous to "developer" over the years that should not have had it. I know this because I spent enormous amounts of time interviewing them in previous lives in order to avoid hiring the ones "who don't get it" with regards to ethics, coding practices and security. I've even blogged elsewhere about The Quiz that I implemented at a certain dotcom [that shall remain only on my resume] as the standard of hiring people onto my team. Developers worthy of the title "get it" with regards to security and privacy regardless of whether they "learnt it in skewel" or OTJ. (Frankly, medical school doesn't really seem to prepare doctors for being doctors, either. That's why they have to go be residents first and learn how to be real doctors OTJ.) Developers are just as scrupulous and ethical as professionals in every other walk of life.

So where do the security violations, bugs and Unofficial Annoyances™ come from that Ms. Davidson is solely blaming developers for? Economics, mostly. Ms. Davidson too quickly dismisses the critical importance of this when she says, "Vendors are pressured to move products into the market as quickly as possible" and then moves right along to continue flagellating developers who neither occupy the board level that she refers to earlier nor truly reflect the consumer base of most of the software products that they develop. Developers (like CEOs) are economic actors who optimize their behavior (more or less) to accommodate the conditions they are presented with in the form of release schedules, marketing campaigns and ever-changing requirements... not to mention actual customers who are very adept at finding uses for products that nobody ever foresaw or intended. Heh.

Developers may be the immediate, visible cause of security/privacy/whatever flaws, and applying strong medicine (such as test-driven development, strict methodologies, etc) can certainly help – it can't completely cure the problem because the medicine is not being applied to the root cause. Developers are (generally) not the root cause of the conditions which result in those flaws. Even virus authors do not set out to produce "bugs" in their own code. No developer does. Unrealistic timelines, selection of inappropriate technology, lack of sufficient resources applied, lack of appropriate methodology, etc, all boil down to things developers typically don't control: budget, timeline and C-level decision-making authority. I'm not saying that gung-ho developers who have never produced a product with the technology selected but they "really think they can do it in six weeks" don't contribute to the problem, but... when presented with a choice of winning the business from the client under the conditions presented, there are developers somewhere on Earth who will agree to the terms in order to get the cash and the chance to work on the project. Management and consumers have taught us well that it's "better to ask forgiveness than to seek permission," right?

Part of the misunderstanding begins with the analogy to bridges, etc. Developers @ work [to date], as a rule, are not engineers by nature and software is generally not engineered. It is crafted lovingly by people who dig their work so much that they stay up late, think about work in the shower (when they shower) and would rather write code than sit in traffic or talk on the phone... Software for many, if not most, developers is more of an obsession at some stage of their career than it is a profession. But nobody (not even me) is willing to pay for and then wait for Perfect Code™ to be delivered because most of us don't have Pentagon-sized budgets and decades to wait for it. Even when we do, does the Patriot missile always hit its target? Does the Ariane rocket always make it into orbit? Does that bridge never need maintenance? Imposing draconian legal penalties for software flaws will not solve the fundamental problem any more than Prohibition stopped alcohol consumption in the U.S. – it will just move more of it offshore.

To her credit, Ms. Davidson has the right idea when she says, "The mentality needs to change." She's just talking to/about the wrong people. Management, marketing and consumers are the ones that need to learn to listen more carefully (and take responsibility for the decisions they make) when developers say, "It will take X more people. It will take X more dollars. And it will take X more years." to accomplish whatever wacky feature is requested instead of demanding that the poor code-monkeys (who just want to write good code!) churn out the product five minutes from NOW for a couple bottles of Mountain Dew and a pat on the back. People do NOT buy software like it's a bridge – they buy software like it's a diaper, a necessary but disposable evil. This is unfortunate, but... We all had a lot of fun during the Year 2000 "crisis" because people did not spend bridge-sized amounts of money on the software and were then surprised when it didn't last as long. When the buyer says that he's willing to pay $5US for that Feature X, then we have to assume (before we even take on the job) that he's done the risk analysis on his own for all the possible outcomes and that $5US is what he think the risk is worth, because if it was a bigger risk, surely the buyer would be offering a reward more commensurate with the risk?

As for the analogy? Building great software is even harder than building bridges to nowhere. At least with a bridge, nobody will decide that (despite what they requested initially) what's on the other side is not where they want to go today...