You haven’t picked come to this web­site expect­ing me telling you a sweet story. You’ll prob­a­bly want to get straight down to busi­ness and read about what will help you as a soft­ware designer and I respect that. I would want the same thing. But it’s my expe­ri­ence that know­ing in what kind of envi­ron­ment we as design­ers have to oper­ate helps immensely. Besides that we have to lay the ground­work, the foun­da­tion on which we can build our designs. Every farmer knows that before you can reap the rewards you have to sow the seeds. And it takes a lot of time, some fine nur­tur­ing, and even some ben­e­fi­cial exter­nal fac­tors, like the weather, have to coop­er­ate, before we can even talk of reap­ing any­thing at all! Design­ers want­ing to deliver a qual­ity prod­uct have to oper­ate under the exact same rules. And it’s these rules we find in these first post cat­e­go­rized under “prepa­ra­tion”. It is my sin­cere belief that the more you know about the envi­ron­ment in which you have to oper­ate, the bet­ter you can adjust to it’s hard­ships. Dar­win dis­cov­ered such a thing almost two hun­dred years ago and since then there’s hasn’t been a sin­gle soul who has come up with some­thing bet­ter than the gen­eral mes­sage he con­veyed at that time.

Besides that my own model con­cern­ing soft­ware design is called “Test Dri­ven Require­ments Engi­neer­ing” (TDR). If you thought that maybe design­ing had some­thing to do with test­ing you’re absolutely right. TDR is a method specif­i­cally designed for max­i­mum re-usability and one of the areas where a TDR design will be used again, far more intri­cately than tra­di­tional designs, is dur­ing test­ing. I don’t know about you but I like to keep things as sim­ple as pos­si­ble when­ever the occa­sion arises. So if I don’t have to do the same thing twice I go for it, but you will read all that and much more in the appro­pri­ate posts. What’s impor­tant to real­ize here is that, if design­ing involves some­thing about test­ing, you obvi­ously have to know some­thing about that area. And although the area of test­ing is severely high­lighted in this design method, it is far from the only area.

I like to com­pare the first set of posts like dri­ving from a cer­tain point to another one. As a dri­ver your first pri­or­ity obvi­ously will be dri­ving itself. “Hey, how do I drive this baby, is there some­thing resem­bling a clutch or do I just floor the gas pedal.” Even then, there are some other areas of exper­tise you have to mas­ter. Like not sit­ting in the pas­sen­gers seat when want­ing to move, or in the trunk for that mat­ter. Seems triv­ial enough, but it still applies. Even when every­thing is where it should be and the dri­ver has both hands on the wheel ready to explore, he still has to know some­thing about the envi­ron­ment. There are things which the major­ity of peo­ple call roads and then there are things which def­i­nitely don’t deserve that name. And even then it depends on the vehi­cle your dri­ving. When dri­ving a mon­ster truck other vehi­cles sud­denly could be called “roads”. Then there are other “dri­vers” or peo­ple try­ing to fit that descrip­tion. And we all know what hap­pens when even one of those dri­vers decides to have some vari­ety and go the oppo­site direc­tion in the same lane. We have a name for that kind of behav­ior which I shall not repeat here. I could elab­o­rate the sub­ject fur­ther but I think you get the point. In any area of exper­tise you have to know what’s out there and with every post cat­e­go­rized as “prepa­ra­tion” you’ll learn this.

At times you may get the idea that posts cat­e­go­rized in “prepa­ra­tion” are out­side of the respon­si­bil­ity of design­ers. That maybe it has more to do with the work man­agers should be doing dur­ing a project. Well you’re right inso­far that maybe the respon­si­bil­ity of plan­ning and man­ag­ing is not in your port­fo­lio. On the other hand if you know that the job you are paid for as a designer will unerr­ingly end like the flight of the Chal­lenger because of bad prepa­ra­tions of so called “man­agers”, isn’t it your respon­si­bil­ity to do some­thing about it? Don’t you have a shared respon­si­bil­ity for the end result? Don’t you and the other project mem­bers are, in the end, try­ing to achieve the same goal? The answer to that ques­tion is obvi­ously “yes”. Lis­ten, being respon­si­ble is not an excuse for stomp­ing on each other when­ever somebody’s wrong, it’s help­ing each other. In the end you’re not only help­ing the other mem­bers with the sub­jects dis­cussed in the prepa­ra­tion cat­e­gory, you’re help­ing your­self by improv­ing the qual­ity of your soft­ware design, because you had the abil­ity to anchor it in foun­da­tion as solid as a rock, or at least help­ing the ones directly respon­si­ble for this foundation.

Prepa­ra­tion has tan­gi­ble sub­jects. And the main one is the one I call the Mile­stone Frame­work. The Mile­stone Frame­work is sub­se­quently bro­ken down into project phases, char­ac­ter­is­tics and parts. Each of them of the utmost impor­tance in lay­ing the foun­da­tion for your soft­ware design.

When we have laid the ground­work it’s time for the the­ory involved with actu­ally mak­ing a design, the main sub­ject of the sec­ond cat­e­gory “exe­cu­tion”. In this cat­e­gory you will come to  know the ben­e­fi­cia­ries of the design inti­mately and how they help to shape the the­ory behind Test Dri­ven Require­ments Engi­neer­ing (TDR). They are of course the end user and the devel­oper. If there’s some­thing you have to under­stand as a designer it’s this, a design has the poten­tial to be much more than just a sta­tic rep­re­sen­ta­tion of a piece of soft­ware. It’s a way to struc­ture com­mu­ni­ca­tion in all sorts of areas if con­structed in the appro­pri­ate man­ner. It’s com­mu­ni­ca­tion between these two stake­hold­ers we have to estab­lish and there are spe­cific things we have to do as design­ers to ensure this. I call the process to estab­lish effec­tive com­mu­ni­ca­tion between these stake­hold­ers “align­ment” and it will be the most sig­nif­i­cant process we as design­ers are to trans­late into our soft­ware design. Align­ment is the way for the designer to keep all eyes focused on the goal. Although I may sound like  a priest divulging ancient rites I will give spe­cific instruc­tions to make sure you will be able to achieve align­ment dur­ing your own work.

In many of the projects I’m involved with I see peo­ple who have absolutely no idea what they’re up against. I see peo­ple wrought with frus­tra­tion unable to cope with the dif­fi­cul­ties at hand. I see peo­ple with extra­or­di­nary capa­bil­ity dis­cussing every minute detail of some prob­lem, but in the end utterly fail­ing to put one step towards an effec­tive solu­tion. I’ve seen peo­ple brake down and cry in more than one occa­sion. Seen peo­ple giv­ing up and stay­ing at home angry at the world. If I tell you that in life you have to set goals in order to achieve them, few will dis­agree with me. But what each and every indi­vid­ual has got to do  when the prob­lems seem to big to swal­low is to chunk them down and set sep­a­rate goals to achieve their attain­ment. With soft­ware projects as a whole its no dif­fer­ent. It’s goal set­ting that spell suc­cess or fail­ure for every project. And it’s soft­ware designs that make goals tan­gi­ble, real and achiev­able. And I don’t mean designs fraught with unin­tel­li­gi­ble mod­els, tables, num­bers and page after page of text writ­ten in some lan­guage from another planet. I mean designs stripped to the bare essen­tials, sim­ple, under­stand­able, read­able for all the stake­hold­ers, not just the so called experts. My god, some soft­ware designs need an enigma machine to decode plus the peo­ple who oper­ated it dur­ing WWII.

Exe­cu­tion will give you all the tools you need as a designer to put your prod­uct together. It cov­ers design­ing with visu­al­iza­tions, require­ments and test dri­ven require­ment engi­neer­ing, test­ing with test dri­ven require­ments and a chap­ter cov­er­ing sub­jects such as man­age­ment infor­ma­tion and time esti­ma­tion with test dri­ven requirements.

After all this rant­ing and rav­ing I want to leave you with this mes­sage. As a soft­ware designer myself I have to prac­tice what I preach. I find TDR giv­ing me new dis­tinc­tions every sin­gle day. I sin­cerely hope TDR will do for you what it does for me which is giv­ing you the edge as a designer and the knowl­edge that you have a skill set not only to achieve the task at hand but also hav­ing immense fun while doing it. For it’s doing a job with pas­sion that brings you and your team­mates to a whole other level.

Related posts:

1. The Soft­ware Design Arena