Software development is hard.

OK, not really. What I mean to say is that doing software development well is hard. It turns out to be surprisingly difficult to consistently produce useful software that doesn’t have serious defects, that is easy to understand and use, and that is feasible to adapt to changing environments and changing needs.

That’s not to say it is impossible or impractical to produce high quality software. We know how to do so, and we know more than one way to do so. It really is a solved problem.1 Yet many software projects produce deficient results. Sometimes this is because the project team is simply ignorant of good practice, sometimes because schedule is more important than any other consideration2, sometimes because the team simply doesn’t execute well.3

A solution

It is hard for people to perform a task efficiently, successfully, consistently and repeatedly. The farther the span of time between each execution of the task, the less likely it is for a person to be consistent or efficient or fully successful.

But we can build machines, software machines, that will perform tasks consistently and repeatedly—even with long periods between executions—and that do so efficiently and succesfully. They can even be made to report successes, warn of failures, guard themselves against making serious errors. We can measure their performance, test their operation, and improve them over time.

If we can convert a best practice into code, then we allow every developer and every project to leverage that best practice easily and correctly. This will mitigate issues of experience, knowledge transfer, and execution. If we can automate a development task or process, then that task can be performed at very low cost, and typically very quickly. This will mitigate issues of schedule and cost.

In short, automating software development activities and best practices should allow more projects to execute good software development and maintenance processes well, and that should result in higher quality software.

What’s next

I am interested in all aspects of software development, and will likely write broadly about it. Primarily, though, I want to focus on automating as much of the software development work as possible. Using automation is, it seems to me, a very efficient and reliable way to mitigate much of the impact that human failings have on software development.

I plan to spend a lot of time investigating that assertion.

  1. Of course methodologies and practices continue to be adapted, enhanced, and invented. And not every methodology or practice is appropriate for every project. The point is that solutions exist, are well known and copiously described—not following them should be considered as a variation from accepted practice and means assuming increased risks. ↩

  2. Typically this means discarding any practices that target long term qualities, like minmizing support costs, minimizing costs of future changes, addressing security concerns, deployment support, diagnostics and other operational support. Although a business case can be made for such an approach, I think such a justification is valid only rarely—unfortunately that will become evident only well after the immediate project is completed. (N.B., using project scoping approaches such as Minimum Viable Product can lead to a project that could use best practices and still hit an aggressive shipping target.) ↩

  3. One thoughtful inquiry is Why We Fail [cite], by Victor Lombardi. Another excellent source of insight is dilbert.com. ↩