What's design got to do with it? In software development, quite a lot. Design can bridge the gaps that may exist within your software team and will ultimately save you time and money.
Design is more than just, well, design. Within software development, process design should be seen as a communications tool. Rather than a team of developers working independently on different elements of the software, often with wildly varying interpretations of what's required, design unifies the team and the process.
It boils down to understanding. By introducing a design step at the beginning of the process, this confusion is avoided. Design brings the software development team towards a shared understanding, or to use a business cliché, they're all singing off the same hymn sheet. Rather than disparate individuals working on different elements – User Interface, User Experience, architecture, coding – that may or may not all fit together, the team, each member with their own unique perspective, is collaborating, making fundamental decisions in advance and gaining cross-functional team consensus on the basics.
Not only that, each member of the team gets to proffer their interpretation of the brief and contribute ideas. This can help with team motivation; there's a buzz that comes from working effectively within a team environment.
That's not to say that everything needs to be, or even should be, designed up front. In fact, designing things in such a way that makes change of direction easy is where it's at and forms the basis of agile software development. Design shouldn't be rigid. Sure, design the fundamentals, but the key here is learning and adapting as you build.
This agile approach goes hand in hand with good software design practise. Design, build, release, test, tweak, release, repeat. But this isn't just a catchy refrain, it saves time, and as we all know, time is money.
An interesting presentation by General Ellen M. Pawlikowski, Commander of the US Air Force Material Command, highlights one of the characteristics of agile development: not trying to fulfil all requirements at once. At the Mitchell Space Institute's Breakfast Series, she talked about how agile development means you can get something into the client's hands, allowing them to get a feel for it. It can often happen that at this stage, some of the original requirements don't make sense anymore “because [users] see how they can actually use it and requirements change”.
This is exactly what can happen with the 'old school' waterfall approach to software development. A team designs everything up front and goes straight into implementation; they test the product and then hand it over to the client. But wait, it's not exactly what the client wanted, and needs to be changed. However, making changes to a finished product takes time. Plus you're under pressure because the client isn't happy.
It's at this stage that the software development team wishes they had come together in the beginning, discussed the product roadmap, designed the building blocks and added a dash of flexibility.
Design sets the scene for successful software development. It encourages collaboration between team members and fosters that all-important shared understanding. But, and this is the twist, effective design is about not sticking rigidly to the design. Be prepared to make changes and tweaks. Requirements change, and good software design will allow you to roll with the changes.
