I worked on many projects in my 30 year career as a software developer. I’ve worked on embedded systems, operating systems, collaboration software, downloadable applications, and enterprise applications—the whole gambit. I’ve done coding, testing, managed developers, been a ScrumMaster, Product Owner and virtually every other role on a development team. The thing I enjoy the most is software design.
One thing that attracts me to design is how important it is to have the right design and how it has a huge impact on the success of a project. Over the last 10 years I’ve really focused my attention on how to design better and learned a variety of techniques and approaches for good design. So it may be a bit of a surprise for you to learn that the more I learn about design the less I suggest people do it—at least not up front.
Whenever I see people do up front design or I do up front design with groups, I find that we spend a lot of time thinking about what could happen rather than what is. Of course, we want our systems to last and we think a good up front design will help us, but in my experience doing a lot of design at the beginning of a project is often a wasted effort. We spend so much time debating about what could happen or what the client might need that we get ourselves lost. What could happen or what the client might need is anyone’s guess. If we have no certainty around requirements then we shouldn’t design for them.
I’ve been running some interesting experiments with developers. I’ll take a group of developers through a two-week training using test driven development. At first, I’ll ask them to develop some software that meets some basic requirements using the approach that is most comfortable for them except that they must write a test before writing implementation. But I don’t time-box them and I don’t tell them anything more than the requirements. Most of the time I see groups spent the first hour or more talking about what they want to build and how to design it. It’s typical for nearly an entire afternoon to go by with little or no code written. Then the next day I ask them to work on another set of requirements but to do it with no design. Very often I get asked, “Really? No design at all?”
I respond, “Do pants have pockets or do pockets have pants?” Of course, they answer that pants have pockets. Then I say “That’s the amount of design I want you to do.” In other words, just state the basic relationships between entities but go no further. Don’t figure it all out up front, in fact I ask them to start coding as soon as you see anything that they can code, first as a test and then make the test pass. If they know some piece of functionality they need then I have them write a test for it and then implement that test and do this over and over.
Developers are often quite hesitant to try this at first but when they do they often see that their velocity starts to increase significantly. I am often asked, “But what happens if we get it wrong?” I suggest that they change it when they find a better approach. What we learn from this is that changing our designs or our code is not that big a deal and often it’s far easier and less time-consuming than I trying to guess up front what the right design might be which in the end is just as likely to be wrong as starting with essentially no design.
With no design up front we are forced and encourage the design as we go and this is really the right way to design for implementation because it keeps us aware of the forces in issues that we’re dealing with. In my Software Development Essentials classes I covered six code qualities, three principles, three practices, three pieces of advice, and 12 patterns that I believe every developer show know. This is by no means is an exhaustive list of things to be aware of but it’s a good start and often it serves as a minimal set of things to get people to be aware of how to do emergent design. Combined with knowledge of refactoring and good discipline in test first development we can often be productive on a project immediately and emerge designs as we go with the minimal amount of reworking.
I’ve tried many development methodologies over the years and I have found none that support good quality software development more than the techniques I teach. The hard part is convincing developers that it really works and there’s really only one way to do that, have them experience it. Developers who take my coding class generate more code in three afternoons of lab time than they often do in a month!
These are things we were unfortunately not taught in school but they are critical for working in software development professionally. So if you’re curious I invite you to check out what I teach. I written a lot about it on my blog and offer lots of resources on my website (http://www.techniquesofdesign.com) but the best way to understand it is to experience it and if that’s of interest to you and I welcome you to attend one of my classes.
Previous Post: « The Scrum Excuse
Next Post: Integrate Early and Often »