Developer's Toolkit

Blog archive

Getting Out of Software Development

I ran into two former colleagues earlier this week at SD Expo Best Practices ( 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 at 1:15 PM

comments powered by Disqus


  • VS Code Now Has Apple Silicon Builds for Native Mac Development

    Goodbye Rosetta, hello M1. Visual Studio Code has been updated with new builds that let it run natively on machines with Apple Silicon (M1), the company's own ARM64 chips.

  • Visual Studio 2019 for Mac v8.9 Ships with .NET 6 Preview 1 Support

    During its Ignite 2021 online event for IT pros and developers this week, Microsoft shipped Visual Studio 2019 for Mac v8.9, arriving with out-of-the-box support for .NET 6 Preview 1, which the company also released recently.

  • Analyst: TypeScript Now Firmly in Top 10 Echelon (Ruby, Not So Much)

    RedMonk analyst Stephen O'Grady believes TypeScript has achieved the rare feat of firmly ensconcing itself into the top 10 echelon of his ranking, now questioning how high it might go.

  • Black White Wave IMage

    Neural Regression Using PyTorch: Training

    The goal of a regression problem is to predict a single numeric value, for example, predicting the annual revenue of a new restaurant based on variables such as menu prices, number of tables, location and so on.

Upcoming Events