Developer Toolbox - Design skills

I came across this quote from Saul Bass and it struck a cord with me.

Design is thinking made visual.

Such a simple and powerful quote. Design is thinking made visual. No special tools required. No certifications, just thinking and writing these thoughts down. As you move through your career in software development it is a great benefit to hone your design skills. Starting out as a junior developer you’re basically given very detailed directions on what is required. As you progress in your career (mid/senior level) expectations are that the you will lead the design and development process. So developing good design skills is key to becoming an effective developer. In this article I will cover why act of design is so important in software development and also cover some software design techniques that developers should have in their toolkit.

What is design

Design by its very nature is different depending on the discipline we are focused on. Design for a graphic artist would involve thinking about what they are going to paint, including the different colours and textures that will make up the composition. For a writer the design process is all about mapping out what they will be writing about, noting down all the points they wish to cover and how long the piece will be. For a software developer design is all about what we are building. What does the software need to do? Who interacts with the software? What data do we need to store?

The important thing for people to note is that there isn’t one way to do “Design”. There are many different and equally correct ways to perform a design process. No one should feel that they are more or less capable of doing so.

Key elements of design

Thinking and creativity

The design process is all about taking the time to think through the task at hand and start working through the solution creation process. Design is not about building anything as that is too costly at this stage. Design at its core is about having freedom to think creatively about a task at hand. Whether your testing out a design for a algorithm, or mapping out the data you need to store for that token data walking through these on paper is a cost effective way or moving your thinking and solution forward.

Iterative process

Design is an iterative process. As the design process continues our understanding grows and our thinking becomes clearer. This process leads to many design iterations, with each iteration building upon the last untill we are satisfied with the result. At this point we share the design with someone else for their feedback. This feedback is (also part of the design process) used to improve our design.

Communication

Once the designs are final (or near final as they can ever be) these designs are an important communication tool for people to understand the final product that will be created, or what they will be working on. Design in the form of drawings or diagrams are a powerful communication tool that enable the designs (and the thinking) to be shared and worked on.

Why focus on design

There are many good reasons to focus on developing your design skills. I have listed some of these below and could probably think about a few more with a couple more design iterations!

Deeper understanding

Often we need long blocks of thinking time to really get into a problem we are trying to solve. Without time to get a deep understanding of a problem or new concept it is almost impossible to make good progress in solving or understanding. Allowing time to focus on the design process enables a deeper understanding of the work at hand. Like peeling an onion deeper understanding is uncovered as we dive deeper into a task. Through our design process with each thought, each sketch or doodle, we get closer to that deeper understanding and the solution goal.

Better Solutions

Design enables better solutions to problems. A solution that has been through a full design process, with peer reviewed feedback across multiple iterations is going to be a lot better than a solution they came up with 5 minutes before a meeting. This may sound a little silly but it is true. If we force ourselves to sit down and work through all the different considerations we will develop better solutions than just diving on in and see how we go.

More innovation

In turn the design process can lead to better innovation or those light bulb moments that come when folks put a lot of deep thinking towards a task.

Cost effective

The design process allows for people to change their mind about their approach to the task at hand without wasting any development effort. This freedom enables the developer (or architect, UI Designer, BA, etc) to discard a suboptimal approach because there is no costs involved. If developers had started to build something to test a solution prior to design this throw away phase would be harder as they have more time and effort invested.

Less Stress

The design process can reduce the stress of our work day. Humans can often fixate on the difficult and daunting tasks at hand and spend time stressing and worrying about these. If we spend time and think through these problems we will resolve our problems quicker and stress less.

How to go about design

As I mentioned above, design means different things to different people and there is no right or wrong way to about about design. I have worked with many folks in software development who felt that were not qualified to do “Design” work. That only architects or specialists should tackle such endeavours. But the quote from Saul Bass should give people confidence that design is something they can tackle.

Peace and quiet and time to think

I am a strong believer in people developing their skills around analysis / design and thinking in general. The best place to start is freeing up time for thinking during your work day and practice. Find a quiet place and put your phone on silent, grab a piece of paper and a pen and dive into the subject at hand. As you gain understanding of your subject make notes to cement your thinking and map out possible solutions.

A pen and paper or whiteboard or one of those fancy rooms with the white board paint on walls are great ways to work through your thought process. Don’t be afraid to write lots or ideas and throw most of them away, it is all part of the process. Eventually you will produce something you’re happy to share with someone else for feedback.

The important thing to note here is that you should not be afraid to sit down and think. It is ok to devote time to design, it will have a positive effect down the track and most likely save you time and effort. Some folks may think that if your not cutting code your’e not doing any real work. This could not be further from the truth.

As a manager I believe if you do not create an environment and make time for your teams to do in depth thinking and design you are limiting your teams effectiveness and innovation potential.

Design and software development

With the focus on software development there are a few specific techniques worth noting to put into your developer toolbox. Now some of these may not sound cool, but they can really help you in your development process. Now this list is not a complete list but a selection of those focussed on software/systems development specifically. We will start with the high level design techniques first and gradually hone in on more detail levels as we progress. Giving a us a top down view of the system we are developing.

Context Diagram

First up is the context diagram. This diagram is used to represent to entire system/module/feature on a single page. It maps out the actors (people or other systems) the system interacts with along with the data flows in and out of the system. The context digram also defines the boundary of the system along with any data stores the system maintains. The context diagram is a great tool to start mapping out a greenfield system or indeed as a learning tool when you are learning a new system for the first time as it provides a high Level overview of the system at hand.

Data Flow Diagram

Next level of detail is the data flow digram (DFD). These diagrams focus on detailing the processes or functions of a system along with their data. Each process or function within a system can be mapped out using a DFD. Where the context diagram was a full system level the DFD zooms in to a more detailed view of the functions that make up a system.

Focussing on detailing:

• Functions/methods
• Data flows (hence Data flow diagram)
• Data stores (database, flat files etc)
• Start and end of the functions.

From your context diagram you can use data flow diagrams to start designing how the system will be built out. Remember this is design we are not dealing with implementation at the moment we are looking to fully map out what we need to build.

Entity relationship diagrams

Entity relationship diagrams (ER diagrams) are used to design data stores, data tables or data classes and the like. Again following on from our Context and Data flow diagrams the ER diagram is the next level in detail we need to think about for our system design - detailed data modelling and relationships. Here we are designing the entities (classes, tables, etc) we need to store to fulfil our processing requirements of the system.

Pseudo code

The lowest level of design is at the pseudo code level or the individual function or logic level. Pseudo code has been around for a long time. During your school days this may have been taught to you as a technique to map out program logic. Pseudo code is plain English text used to notate programming logic. The benefit is that it doesn’t relate to a specific language and it is very easy to read and understand (even by non-programmers). Designing program logic with some basic Pseudo code is a quick way to note down what your code needs to do.

Why use Pseudo code instead of your favourite language I hear you ask? Well Pseudo code is not tied to any syntax checks so your free just to map out pure logic to your hearts content, all you need is a paper and pen or your favourite text editor. Our pseudo code is the bottom level of design of our systems. Here we are designing the logic for our functions/processes that were defined at a high level in the about diagrams (Context, Data flow, ER).

Conclusion

I hope you have enjoyed this article. My aim in writing this was to empower software developers and indeed folks in general to take some time out and focus on developing your design skills. Design is not the domain of highly paid architects or industrial designers or artists alone. Each and everyone is capable of using design skills to improve their output creativity and innovation.