Once upon a time, hardware was hardware, software was software and business was business.

In those days, cross-functional fraternization was frowned upon in most organizations. About the most one could do was write a memo—and then throw it over the wall and hope that something positive would happen.

Those were days in which computing power was extremely expensive, relegating it to very specific and tactical use. Yes to computerizing in Finance. No to computerizing anyplace else.

The proliferation of user-friendly computing tools and increasingly more affordable computing power brought about computerization projects almost accidentally.

Database projects are a perfect example. Tools like FileMaker, Access, and other predecessors made it relatively easy to gather up a bunch of information, build out some forms, and generate some reports.

Similarly, Web development comes from humble beginnings—think HTML—that were so lacking in complexity that learning them was easy.

And so, someone has a great idea, it gets implemented, it saves time, everyone uses it, and—voila! You suddenly have a Software department.

Maybe someone in that Software department takes it upon him- or herself to become technically adept. Maybe someone is hired in who is technically adept.

But here is the real kicker: who is managing this activity?

I can answer that question easily: it’s someone who has good domain knowledge, is a natural leader and is fundamentally pretty smart. It is NOT a trained Software Development Manager.

It’s an Accidental Software Development Manager. And often a Reluctant Software Development Manager. And perhaps even a sucker. But it is almost never a trained Software Development Manager.

Our clients in industries with a lot of field workers are great examples. Mobile computing is transforming these companies. Computerize work orders. Distribute work orders to people in the field. Collect completion data. Invoice for services performed. Heck, they can even collect a credit card payment on the spot. And the Software Development Manager? Well, in many cases, it happens to be a person who has a great grasp of the core business, and also has a pretty good grasp on how technology can be leveraged in the business… so it is often someone who is a great lawn care expert or plumber, but is in many cases NOT a trained software development manager.

Our client in the consignment business has a completely custom inventory and sales system. It generates barcode tags that can be scanned at sales time. It calculates commissions due to consigners. The Software Development Manager? She can predict exactly what any piece of china or crystal will sell for. She can tell you if something is tchotchke or cherished.

There is another way in which the Accidental Software Development Manager is born: the Hardware Manager needs a desktop- or Web-based configuration tool, or a reporting tool, or a dashboard. Someone in the Hardware group figures out how to create this. Done, right? Wrong. Fast forward five years and suddenly these desktop- or Web-based tools have proliferated, are key features or distinguishers for the product that make or break it. And who is managing this activity? The Hardware Manager is still managing it, along with all of the other products and projects that were there before.

The management of software development is a unique activity. It does require some knowledge and training. Consider all of the areas of expertise that a Software Development Manager must embrace:

• Proper source control
• Maintaining a controlled release environment
• Automated builds
• Proper testing procedures
• Proper architecture
• Technical debt and refactoring trade-offs
• Constantly evolving tools and toolsets
• Knowing when to stay the course with a chosen tool/framework/platform and when to jump ship
• User interface and user experience design
• Maintaining metrics on developer throughput
• Maintaining metrics on fragile, buggy or confusing areas
• Providing adequate user support
• Attracting, hiring and retaining good technical personnel
• Training and re-training technical personnel
• Controlling size and timing of releases
• Preventing scope creep
• Handling crippling issues when they are reported
• Gathering requirements from project stakeholders
• Getting accurate estimates for feature implementation
• Prioritizing features and functionality for inclusion in releases
• Knowing when to buy off the shelf or build in house
• Scheduling and resource allocation

What plumber is going to know all of that?

It is a daunting list, but the Accidental Software Development Manager can actually learn the key information and the best practices fairly easily. It isn’t as simple as googling the topics and reading up on them. There is so much…uh…garbage on the Internet that it gets very confusing very quickly. And books, which at least involve more effort to put together than a rant in a blog post, are very uneven. Some are written for the skilled practitioner. Some are skewed toward a specific philosophy or methodology. So the best way to learn is to be mentored.

Stout’s Chief Technologist Dave Sweeton and I have many years’ experience working with companies and software development teams of all sizes and types. We have accumulated a trash heap of worst practices. And we have accumulated a very small stack of best practices. It would be our pleasure to share them with any of the Accidental or Reluctant Software Development Managers out there. In a language that can be understood and in a way that assumes no prior insight or experience with the topic.

Starting in the fall we will be presenting a series of seminars for the Accidental or Reluctant Software Development Manager. Send me an email. I would love to know of your interest and what your Achilles’ heel topics are. www.stoutsystems.com/contact