Software development is complicated to understand, and even more complicated to do. What's worse, developers disagree among themselves about nearly everything. Nonetheless, it's worth understanding at least the basics of what they do, confining ourselves here just to software process, ignoring (for now) the far more important software substance.
Software Terminology
Most of the talk you hear about software is about process, things like requirements, design, how and when testing should be involved, etc. There is a sea of specialized language about every aspect of software process, much of it coming from conflicting methodologies.All of software process can be boiled down to a small number of basic, understandable things.The main steps are nearly always:
- defining what you're going to do
- how you're going to do it
- doing it
- checking it
- delivering it
What are you going to do?
Whether it's called "requirements" or "user stories," pretty much every software process starts here.
How are you going to do it?
This one amounts to the design phase. Are you going to use a DBMS? Existing libraries? Are you going to apply design patterns? Usually groups have strong preferences for these things, so the usual decisions are endorsed and people move on.Do it
Finally! People actually do stuff!Check it
If there were a software equivalent of the Garden of Eden, in which software happened without bugs (sin), I am unaware of it. So everyone assumes that someone (probably the other guy) screwed up, and we need to fix it.
Deliver it
Finally the software needs to get from where it's built to where it's used. The methods and destinations vary, but that's what happens in this final step.
This is all process
What I've done here, as critics would say, is "over-simplify." Given the incredible number of different software philosophies, this is understandable. Even within a philosophy, differences that seem minor to outsiders are of crucial importance to those who care about that kind of thing.This is all just process! We're just talking about formalities. For example, the process I've described also applies to building a physical structure. The same steps apply whether you're building a simple house
or the Taj Mahal.
If essentially the same process can result in a world-wide tourist destination or a starter home, is process really the most important thing? In other words, substance is vastly more important than process.
Nonetheless, Process still matters
If substance is so important, should process be ignored? Of course not -- having a sound process is essential. The five steps I defined above need to happen, and depending on the process, appropriate sub-steps as well. For example, unless and until you hire programmers directly from the programmer equivalent of Eden, checking is a non-negotiable requirement. That's exactly why it's important to understand software process in these extremely simple terms. It's got to happen.
But then you spend most of your time and effort on building your starter homes or your Taj Mahal. In other words, you concentrate on the substance.
Comments