The Importance of Software Design (damn!)

If you just accept that any non-trivial effort in software engineering requires a deep knowledge of software design principles, a set of quite sharp minds, a lot of common sense and a good deal of trial and error; your life will be much easier and rewarding.

There's no such thing as: "Lets plan, break down the work, select the easiest/repetitive tasks and assign them to the junior people on the team". That just doesn't exist, or even better, it shouldn't exist, because if you ever find such a statement valid, I can tell you for sure you're doing something wrong.

If you've gotten this far, probably you're asking yourself either:

a) how could this guy make such a bold statement without any hard facts backing him up? or;

b) who's this asshole thinks he is?

The answer is quite simple. Software engineering has some very interesting similarities with other industrial production systems which are very useful to organize our work, but also some very specific differences that make it more similar to, say, oil painting. Keep reading, hopefully it'll make some sense.

One of these key differences lies in how easy is to actually build and shape your assembly line, the machines, the workers and all the parts of your production system. We could generalize and say that proper design does not leave any room for simple or repetitive work. If you do have repetitive work – J2EE, remember? – design is wrong. The process of crafting a new piece of software is all about design, solving new problems every time. Reusable components are very useful when user requirements repeat themselves, which is as common as many people like to believe.

What about the RAD tools then? Well, they are a bunch of design decisions that, hopefully for their makers and users, will fit a wide set of common/generic use cases, but as anyone who uses them seriously knows they save time upfront and tend to fall short in the long run – which is just fine.

Knowing that design takes time and brains saves money. A lot of money, and time and stress.

Does this mean that there's no place for juniors in software development? NO. But it's not like you would imagine where simple tasks are assigned to newbies, but more like the master-student relationships the artisans usually build. Juniors are supposed to solve the same problems as seniors, but guided by the laters and learning a lot in the process, bringing also new ideas and synergies to the table. This is the way that people really learn to create, the other way they will learn to copy and paste, or if they are good they'll get really frustrated.

So, to keep this short: If you are about to undertake serious software engineering in any form get you a good team, disregard or challenge anyone that sells super rapid ramp-ups, lots of juniors upfront, magic frameworks that only leave repetitive/configuration work to the dev team, concentrate on your business and users, be sensitive about them, be open to chat about business goals with your developers, build an engaged team, don't ask for a Gantt chart, embrace agile in your heart. You'll love the results.