Tuesday, April 13, 2010

The decencies of software development

Software development projects, like other societies, have a class structure. In part, the class distinctions are marked by money. But with software development, the distinctions can also be marked by discipline. (Which is perhaps not too far from society in general.)

Members of the high end have lots of nice goodies. Members at the low end have the basics but not the luxuries.

Between luxuries and necessities are the "decencies", those things that make one decent, or acceptable to other members of society. The middle class has decencies and some luxuries.

Software development has progressed over the years, and the luxuries of yore are now considered necessities.

The obvious necessity is the computer. Computers have changed from the large, room-filling beasts to the small, pocket-sized pets of today's iPhone. The change was marked with the early microcomputers of 1977: the Altair, the Apple II, the TRS-80, and their cousins. It was complete with the introduction of the IBM PC XT in 1983. Once these computers were available, serious development could occur on PCs, and serious developers needed PCs. Access to a time-sharing system was no longer acceptable, was no longer "decent".

In the 1980s, the IDE became a necessity. Turbo Pascal and the UCSD p-System introduced the idea of the integrated development environment, and it quickly went from luxury to necessity.

In the 1990s, version control moved from luxury to decency, and then to necessity. Building software without version control is unthinkable today.

In the past decade, we've seen the rise of automated testing. Some may consider it a luxury, but I think of it as clearly a decency and probably a necessity.

So what's the next big thing for software development? What's the next thing to move from luxury to decency and then to necessity?

I'm not sure, but I have some ideas.

First, I'll observe that the tools I have listed are all tools. They are things. They are not techniques such as code reviews or computer science concepts such as formal methods.

Second, they are used by developers. They are not practices used by managers, such as project management offices or life-cycle management systems.

Which is not to say that code reviews or project management offices are bad things. I think that they can be good things -- or bad things, if executed poorly -- but they won't be widely adopted by developers. Especially by developers on small projects, or developers on "teams of one", who have adopted the tools of IDEs, version control, and automated testing.

I also think that the new big thing will not be a new language or programming technique. I considered object-oriented programming for the list, along with event-driven programming and GUI programs, but left them off. They all help with windows-type programming ("windows with a lower-case 'W') and that is what drove their acceptance. (Of the three, object-oriented programming helps the development team the most, with its ability to group and organize code.)

The next big thing won't be a new programming platform. It won't be C#/.NET or Java or Python or Ruby. At least not any of them specifically.

Here are some ideas for the next thing that will be adopted by development teams as a decency, something that is required for a mainstream development project:

- Virtualization. The ability to run other operating systems, or start and stop instances of a machine.
- Platform-independence: Tools that produce programs that run on multiple platforms, such as Windows, Linux, and iPhone.
- Service-oriented architecture: Probably with a new name, as "SOA" seems to have a stigma. Organizing functionality behind services (specifically web services) will let development teams move faster in the long run.

In ten years, we'll look back and wonder how we got along without the next decency. In twenty years, the freshmen developers will look at us in awe, or possibly horror, as we recount the days of development on leased computers with separate compilers, no version control, manual tests, and tightly coupled system designs.

Yay! for the future!


No comments: