Software-Design

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. ...