It was when I first started out as a developer I first heard the phrase “designed on the back of a fag packet” (cigarette packet for those not in the UK or Ireland).
It was a typically Scottish (i.e. acerbic) way of describing the lack of diligence of certain designers/developers.
At that time and where I worked, a lack of proper design was as close to cardinal sin as you could get. To put things in context, these were the days of waterfall projects with large requirements and design specs delivered in advance of even thinking about getting your coding hat on.
Fast forward 15 years (give or take a couple) and software development techniques seem to have changed somewhat. We now seem to have charted a course through an agile hype cycle where the point at which we have reached so far is still up for debate (perhaps I’ll leave that for another post).
What I can see is that application or systems design seems to have become a casualty of this revolutionary journey so far. *
And let me clarify, when I refer to application or systems design I am not referring to UI design. Conversely, UI design (I include usability, information architecture, UX, visual design aesthetics, etc) seems to be on somewhat of an upward trajectory. And not before time.
No, I have been deliberately precise in my wording when I say application or systems design. What I mean by that is everything from the high-level layered application architecture, to the low level design application flow, state transitions and design patterns.
Systems design for some seems to be a thing of the past, a reminiscence if you like. For some younger developers it is treated almost as a fable.
So, collectively where are we actually at now? Are we at the stage where cigarette packet design is either overkill or just aspirational?
Well for what its worth, here is my take on it. Unless the deliverable dictates it (note, not the project but what you are delivering) then waterfall style projects are an unworkable methodology for the vast majority of development projects. And with it go the tomb-size design specs that you get sign off from the client.
Instead, appreciate and understand that the requirements are going to change. Either the client is going to change their mind, a change in the market you are building for is going to mean a change of direction or some other unforeseen change of events. Whatever the reason, a change in requirements is going to dictate that you adapt your design. This means being adaptable to change with your design. Not simply skipping design, because “well, why bother, its gonna change anyway, right?”.
To be adaptable, use whatever tools work for you in order to ensure you go through the design process. The act of just doing it is beneficial.
Put things down on paper or up on a whiteboard. Or using your favourite documentation or diagram tool. Or on the back of a cigarette packet even. It doesn’t matter.
The notation you use isn’t as important as some people would have you believe. Providing you and your team all understand it, then you have met the purpose of notation anyway. Its all just language and communication.
It doesn’t matter if its object modelling, entity-relationship design, enterprise architecture or any other level of detail or perspective, just capture it. And this applies equally if you are reticent about UI design also.
It doesn’t matter if you are a single person outfit or a large team.
It doesn’t matter if you are both the producer and benefactor of this design, get it out of your head and on to some other medium.
The act of putting it down is the most vital part of the design process. I guarantee it will get you thinking and asking questions of your design way more than leaving it in the murky confines of your head.
And that is before having the additional benefit of having produced artefacts to reference while developing. Again, if you’ve scribbled it on the back of a cigarette packet or on a whiteboard all is not lost. Get your smartphone out, take a photo and upload it to your repo, wiki, Google doc, Slack channel or whatever tool you are using.
Use whatever techniques work for you, even a beer matt or cigarette packet, but don’t abandon the principles and disciplines of your profession altogether.
What is your experience of systems design?
Are you still doing it?
Do you value it?
Is it just my view that is coloured on this?
There are of course exceptions to this, I am speaking generally and from my own perspective. I am thinking in the context of Line of Business or consumer app design and development rather than real time or control & instrumentation systems programming. These are “proper” software engineering disciplines should be treated as a field of their own. Notions of flaky agile methods and cigarette packet design is doing these engineers a disservice, much in the same way lumping LOB app developers with structural engineers is.