Software development is an art, but it is also a learning process. No artist sits down and creates a masterpiece in one go. He dabbles and tries a few different options to see what works before deciding on a final approach.
In the same way, a developer should learn as much as possible about what works and what doesn’t work for a given problem before settling on a final design. Avoid premature design finalisation (PDF), it just spoils it for everybody.
Use a pencil
I attended a Developer User Group meeting last week. Brett Powel, one of the presenters, spoke about Evolutionary Design and one thing he mentioned really got me thinking about our approach to design… software development is a learning process.
Just to clear up any confusion, by “design” I don’t mean application architecture or choosing a technology stack but rather more design pattern level, even class level design. As Robert C. Martin put it “All development is design.”
I bet you have looked at a design weeks or months later and thought this design would have been so much better if you only did this or changed that? Only problem is that you are so far down the path with this design it will take too much effort to change it. In short, you have painted yourself into a corner, all pun intended.
You should learn as much as possible before making any critical design decisions. Avoid using oil paint on your canvas and stick with a pencil for as long as possible.
How to design like Da Vinci
Here are some points from Brett’s talk that I adapted a little so it applies to more than just evolutionary design.
Do minimal design upfront. Only put together a basic outline of what needs to happen. Don’t create a final design before you have even written a line of code or learned anything. It will also stop you from over designing a la conspicuous cleverness.
Generate multiple designs and try to keep the design in such a state that you could move to any of them for as long as possible. This really forces you to hold out and avoid PDF. An added bonus with doing this is a lot less coupling in your design, which is always a good thing.
The only way to learn from your design is to test it and see what works and more importantly, what doesn’t work. Taking a page from evolutionary design, design and code as thin a vertical slice of the solution as possible. This will allow you to test your design and fail fast.
You then adapt the design as you learn. Keeping what works and cutting off the bits in the design that don’t work, like Van Gogh.
Paint by numbers
In the end software development is an art and unfortunately not the paint by numbers type. It takes hard work and a lot of experience and learning to become great at it. Even if you are at the Dogs Playing Poker level now, the more you learn the closer you will get to painting the Mona Lisa.
At this point I also want to coin a phrase you can use when you see a bit of awesome software design, you can refer to it as “Da Vinci’s Code”.
Leave a comment about what you have learned from your experience of painting yourself into a corner, how did you remove the paint from your feet?