Software-Design

I find that software developers struggle to sketch diagrams of their software. They get lost in the specifics of diagraming techniques, in choosing from the many available tools, or in the futility of drawing diagrams at all. I understand their pain, as there are many standards for diagrams and many (often obtuse) tools for drawing with. It’s not very motivating to have a sea of choices, none of which looks particularly appealing. ...

I wrote my first computer program when I was 8. It was a simple adventure game written in BASIC, a mess of GOTO and PRINT statements. I saved it to tape a few times, proud enough of my first creation that I didn’t want to lose it. And despite what I didn’t understand my mind exploded with ideas. I continued to write games and curios into my early teens. I wrote text adventures and arcade ripoffs. I hacked at biometric data collection using a busted set of paddles and mixed mode graphics. I designed and built a large (but clunky) side scrolling adventure game using only a set of customized fonts. I plagiarized code from magazines and hacked at my machine until the wee hours of the night. ...

I’ve been busy working on visual design bits for work projects this summer. My method is simple: Sketches and storyboards Static mockups (HTML/CSS, some Javascript) Live mockups (to test integration and interactions) Uncovering what a feature means is fundamental to the method. It exposes the nouns and verbs of the problem, and hints at the useful metaphors. The freeform nature of sketching and developing storyboards based on this language helps me focus on figuring out what the things mean, as well as finding their shape and rhythm. I end up working on several different approaches before it’s obvious which ones are workable for the client and product. ...

While writing a spec earlier today the last few years of progress in server land hit me: uptime is a facade. In the early days, server resources were expensive and scarce. Uptime was sacred. Long running hardware was celebrated, UNIX tools were born, beer was consumed. The problem of focusing on the hardware is that it detracts from the time you spend developing software. Remember those late nights configuring RAID setups? What about hunting down faster drives, or terminating SCSI cables? ...

I’ve become passionate about design. It’s a subtle craft that says something, things that can’t normally be said with words. It suggests things. It implores us to think in a particular way. It encourages us to go here or there. It is enough of a metaphor to be easily recognized, but not so much that it becomes tacky, unless of course tacky is the thing you need. Design is the artful side of craftsmanship, the soul of a thing. ...

I know a few generations of developers. I find they tend toward different ways of thinking about software design, based on the languages and decomposition tools that were available at the time they formed their thinking. Their tendencies shift over time too, but often their imaginations are limited by whichever mode of thought they’re working in at the time. By design I mean the approach to solving a problem with software, including software architecture and low level design (not product, visual, or UX design). These are another universe around how we think about solving people’s problems with software, a topic for another set of posts. ...

When you describe a design to a group of people, each person imagines something different. Depending on your story and the individuals, understanding may vary wildly. And if it differs enough, the result is chaotic–unpredictable and often negative. You need to fit how you show your ideas to different groups of people carefully, and notice when you your story isn’t hitting. For your closest team members you can wave your hands and scrawl ideas on a chalkboard. For people you work less frequently, you need more detail: proper drawings and clean wireframes. For non-technical clients you need even more, polished, functional prototypes and pretty drawings. ...