Getting Out of Software Development
I ran into two former colleagues earlier this week at SD Expo Best Practices (
www.sdexpo.com) in Boston. These gentlemen (don't let them know I called them that) now work at high-level software engineering management jobs at a major systems and software vendor (we now know which of us succeeded professionally and which of us didn't). The last time I was in touch with them, approximately two years ago, they were the vice president and software development director of an enterprise messaging product line for this vendor. Today, they make up the entirety of a two-person department whose job it is to standardize software engineering practices across the vendor's software groups.
What happened?
It was at their choice, they informed me. Their enterprise messaging and message management product was failing for technical reasons. Our product worked fine in the lab, one explained. Then it started failing at customer sites. We went to investigate, and found that people were forwarding messages to 10,000-person distribution lists, with twenty-two attachments. And they told me several other tales of e-mail that were just as absurd.
How do you archive something like that, and make it searchable? And a good part of the problem is that the APIs they were using (especially MAPI on the Microsoft side) didn't deal with these edge cases well. But there were also issues in parsing Microsoft and Unix formats to come up with a common management approach.
All of these are probably solvable, given enough time and code. But they are not particularly enjoyable problems to solve. And they are the kind of things that we would normally consider bug fixes, not features. Worse, they take time out of the schedule, which was probably overly aggressive to begin with.
So these gentlemen (there I go again), both well-paid and highly qualified professionals in their mid-40s, choose to work to improve development processes instead, rather than deliver production software. In any other field, these types of people would be reaching up to the next rung of responsibility. What is it about software?
When I relayed the story to a colleague, he remarked, People do crazy things with e-mail. That is undoubtedly true. But if we provide the feature, it should work consistently under all circumstances.
It is a problem of our own making. Unlike just about other engineering profession, we have failed to standardize on shared infrastructure. Instead, those things that should be implemented, repaired, and enhanced once across all platforms are instead implemented separately. They work differently, depending on your language, operating system, and perhaps even your intended application.
If it is our problem, it is up to us to fix it. The infrastructure that multiple vendors depend upon must undergo some standardization. If a piece of infrastructure has a bug, or is not robust enough, it need be fixed only once to service all of its users.
If we don't do so, other talented software development leaders will abdicate the responsibility of delivering quality software.
Posted by Peter Varhol on 09/15/2006