Designing Software In Photoshop
December 5th, 2006[ Software Development ]
“In the pitiful, multipage, connection-boxed form to which the flowchart has today been elaborated, it has proved to be useless as a design tool — programmers draw flowcharts after, not before, writing the programs they describe.
Second, the screens of today are too small, in pixels, to show both the scope and the resolution of any seriously detailed software diagram. The so-called “desktop metaphor” of today’s workstation is instead an “airplane-seat” metaphor. Anyone who has shuffled a lap full of papers while seated between two portly passengers will recognize the difference–one can see only a very few things at once. The true desktop provides overview of, and random access to, a score of pages. Moreover, when fits of creativity run strong, more than one programmer or writer has been known to abandon the desktop for the more spacious floor. The hardware technology will have to advance quite substantially before the scope of our scopes is sufficient for the software-design task.
More fundamentally, as I have argued above, software is very difficult to visualize. Whether one diagrams control flow, variable-scope nesting, variable cross references, dataflow, hierarchical data structures, or whatever, one feels only one dimension of the intricately interlocked software elephant. If one superimposes all the diagrams generated by the many relevant views, it is difficult to extract any global overview.”
Tools like UML are nifty, and if you have no choice but to convey a software design on paper then that’s where I’d point you. Remember though, it is still an ugly hack, in my opinion. Architecturally, at BOC, we strive for a design-build methodology where the guys designing the software are the guys building it. Sure it opens yourself up to the hit-by-a-bus syndrome but experience tells us that very few of our people get hit by a bus on a regular basis so it’s an acceptable risk.
The ideal tool for describing a software design is a modern programming language, in other words write code. In The User Illusion, Tor Nørretranders explores a powerful metaphor for human consciousness. One of the examples he uses is maps. As you add more and more detail to a map you have to add more and more information. In the end the only map of the world that has enough information to convey it accurately is the world itself. Anything else is just a best guess and is missing valuable information. The same applies to software, the only thing that conveys a piece of software completely is the piece of software.
There are good reasons to document the software development process like conveying a design to a team of developers who are tasked with implementing your design, or documenting what’s been built for subsequent development, etc. A reason I’ll never put on that list is that it makes for better software. Am I saying you don’t have to plan a lot on paper before hand? No. Am I suggesting you always jump to code and write first? No. I’m suggesting you only document on paper what you as a designer feel will move you towards better software.
Even in the cases where I have to document a design in order to hand it off to a team, I will typically design the system in code. I’ll write up a simple, stripped down version of the application in code and then I’ll document the application I’ve built in order to create documents to hand to the team. If you think about that it ain’t optimal.