Introduction

Why a blog about the process of software development/creation? I've been a student of software development processes since the early 80's. There are still books and papers from the history of this subject stacked in various corners of the house. As an example, here's one that I picked up fairly recently in a used bookstore on my way to NYC.

This book was published in 1982. Apparently, there was a revolution in software engineering underway then. What kind of revolution was it? Let's have a look. Here's a few items from the Table of Contents.

• A Technique for Software Module Specification - D. L. Parnas
• Program Development by Stepwise Refinement - N. Wirth
• Design and Code Inspections to Reduce Errors - M. E. Fagan
• Notes on Avoiding "GO TO" Statements - D. E. Knuth & R. W. Floyd
• Mathematical Foundations for Structured Programming - H. D. Mills

These titles sound very formal on one hand, and somewhat basic on another hand. How does an article on avoiding 'goto' end up beside an article on the mathematical foundations of structured programming? Since this is an introduction to the blog, I won't talk about these articles here. I may hit on some of them later. I will quote from the N. Wirth article to give a taste of what was 'in the air'.

"In each step, one or several instructions of the given program are decomposed into more detailed instructions. This successive decomposition or refinement of specifications terminates when all instructions are expressed in terms of an underlying computer or programming language..."

It would be interesting to look at writing an ex post facto manifesto of the Structured Programming 'revolution' so that it could be compared with the Agile Manifesto. Many of us were caught flat-footed by the Agile Revolution. I know I was working to fix some of the problems with 'traditional' top-down development approaches. I very quickly realized that this work had been 'overcome by events'.

I have worked successfully on large and small projects in the Agile world. Agile has really advanced the state-of-the-art and given us many new tools that will be in software development processes for a very long time. Maybe the greatest achievement of Agile was stopping the 'software is 90% done for 50% of the time' problem. It certainly cut the analysis paralysis problem, too.

And yet, the movement to Agile seemed more like a religious conversion than a thought-through move to something better. The Agile Manifesto was to be accepted not rationalized. Past 'non-Agile' successes somehow disappeared. In religious terms, the moral agent in the process shifted from the designer to the coder (will explore this in a future post). Software - which was once thought of as being developed by defrocked mathematicians, is now the creation of the Coder-Artist.

So I'm writing this blog because I want to explore this territory. Certainly I want to document and understand the inflection from software-as-math to software-as-art; but also to consider what's next. I have some ideas.