Software Practices - Sandwich Design

Today, I was reading a colleague's blog. In his last post (in Spanish) he defends the programmer as a software professional and provides a great outlook of its —generally misconceived— role, duties and difficulties. That immediately reminded me about the opposite figure: the architecture astronaut as described in Joel Spolsky's article. At some companies both roles officially exist (software astronauts not being desing as such but in other pompus terms). Sometimes they even group them into separate buildings, Kilometers away from each other.

What does all this has to do with this post's title?. Well, I dare say that officially separating both roles warps each individual's mind towards two software design approaches. Top-down and bottom-up. Analysis and synthesis.

Astronauts deal with ideas, designs and hopes. They analyse a problem. They concieve a view of the solution and try to put it somewhere, somehow. Call it a UML diagram or whatever. They generally don't care too much about technological or programming issues, as every difficulty can be overcome, and think the hard work is done. Remember, top-down. Once decomposed it should be easy.

If you ever wrote a line of code in a medium-sized project —which you might not if you're in the Cosmo Team— and you're humble and honest —scarce virtues— you know that, at this point, the process just reverses and it's not easy at all.

Programmers need to deal with lines of code and machines. They are forced to syntethise, given their circumstances. They take some sort of specification, design —when lucky—, a technological environment in form of software and hardware and need to combine all this to produce something that works —or, at least, appears to—. In some way, it's pure bottom-up. The programmer's materials for the building process are existing technologies, libraries, language primitives, etc. that must be mixed together "upwards" to match the design, functionality or specification. The same materials that might have been overlooked during the analytical process.

This is the main reason why, when left alone —probably by inertia—, most programmers take the bottom-up approach. The bad news is that they generally forget that the bottom-up approach is also a design approach that also involves an analytical process. But they generally rush to code. When the main program and some tricky parts are outlined the hard work is done. Remember, bottom-up. Design will magically arise and every piece will fit. Once a few things are outlined or coded it should be easy.

Same dog, different collar?. Sure. Now a different set of problems arises: forgotten functionalities, huge refactoring efforts, this-is-not-what-I-expected user dissatisfaction, etc. but that's another story.

So, why don't we take the best of both worlds and use 'Sandwich Design' practices?. Let's analyze the problem without overlooking or ignoring the building materials, skills or details. Let's take a wider point of view and try to provide a solution from both sides, from the top and from the bottom.

In the software development world you'll often see architecture astronauts proposing completely absurd, complex or already solved solutions. You'll often see programmers who excel at programming and know about tiny pieces of technology that could potentially solve complex problems but who don't care at all about what the general problem is.

I think that working from both ends, analysis and synthesis will converge more easily, also mitigating friction among teams and processes and providing a shorter schedule.

This is much easier to achieve in small or medium-sized companies that take a more integrated approach in Software Development. In fact, I believe the best ones really forget about prejudices and myths, roles and methodologies and, aware or not, are using Sandwich Design all the time.