When you’re doing programming, you have to explain something to a computer, which is dumb. When you’re writing a document for a human being to understand, the human being will look at it and nod his head and say, “Yeah, this makes sense.” But there are all kinds of ambiguities and vagueness that you don’t realize until you try to put it into a computer. Then all of a sudden, almost every five minutes as you’re writing the code, a question comes up that wasn’t addressed in the specification. “What if this combination occurs?” It just didn’t occur to the person writing the design specification. When you’re faced with doing the implementation, a person who has been delegated the job of working from a design would have to say, “Well, hmm, I don’t know what the designer meant by this.” It’s so hard to do the design unless you’re faced… Read more →
EppsNet Archive: Software Design
Amateur Design
The worst scenario I can imagine is when we allow real customers, users, and our own salespeople to dictate “functions and features” to the developers, carefully disguised as “customer requirements.” Maybe conveyed by our Product Owners. If you go slightly below the surface, of these false “requirements” (“means,” not “ends”), you will immediately find that they are not really requirements. They are really bad amateur design, for the “real” requirements — implied but not well defined. — Mary Poppendieck Read more →
Every New Feature is a New Failure Point
The TPMS warning light on my car dashboard is lit up, which, according to the owner’s manual, indicates a malfunction in the Tire Pressure Monitoring System, a system designed to alert me, via a different warning light, when the tire pressure gets too low. It’s a completely unnecessary system to begin with because I can monitor the tire pressure myself, as drivers have done since the invention of the automobile. Let’s add a completely unnecessary new system so when it breaks, the owner will have to pay to fix it. Can I just ignore the warning light? I don’t know. The worst-case scenario is that the TPMS not only breaks but creates a domino effect that knocks out a critical system that I actually need. Toilers in software development can draw their own analogies . . . Thus spoke The Programmer. Read more →
Rough Layouts Sell the Idea Better Than Polished Ones
This was written by an ad man but I can see it applying to other endeavors, like designing a software interface: If you show a client a highly polished computer layout, he will probably reject it. There is either too much to worry about or not enough to worry about. They are equally bad. It is a fait accompli. There is nothing for him to do. It’s not his work, it’s your work. He doesn’t feel involved. If he doesn’t like the face of the girl in your rendering, or the style of the trousers on the man on the right, or the choice of the car he’s driving, he’s going to reject it. He won’t see the big idea. He will look at the girl’s face and think, ‘I don’t like her, this doesn’t feel right.’ It is very difficult for him to imagine anything else if what you… Read more →
Kanban, Scrum, User Stories, System Design
Scrum-ban Kanban bootstrap Elements of taskboard design A Kanban System for Software Engineering Naked Planning Explained – Kanban in the Small Kanban Development Oversimplified The new user story backlog is a map Read more →
Customer Engagement
You want to actively elicit feedback from end users using short development cycles or by using prototypes and models during analysis. A good feedback cycle has the appearance of causing problems. It will cause emergent and latent requirements to surface. That means rework: the value of prototypes is that they push this rework back into analysis, where it has more value. And most important, good end user engagement changes end user expectations. It is only by participating in a feedback loop that’s grounded in reality that customers get the opportunity they need to reflect on what they’re asking for. If your customer changes their expectations in the process, you’ve both learned something. Embracing change doesn’t just mean reacting to it: it means providing the catalysts that accelerate it. — James O. Coplien and Gertrud Bjørnvig, Lean Architecture for Agile Software Development Read more →
Convergence
The distinctive conduct that marks successful project teams is this: They know there is a time to diverge and a time to converge. That is, in each of the project planning phases (e. g., feasibility, conceptual, definition, execution), the team first moves outward (diverge) to gather information and ideas and to generate alternatives — only then does the team move inward (converge) to focus, evaluate, and select. — “Ninety-Nine Rules for Managing ‘Faster, Better, Cheaper’ Projects” Read more →
Visualize the Properties
Imagine and identify the few properties of your product or service that will gratify the customer’s need. Visualize the properties, desire them yourself, and everywhere ensure and intensify their presence. — Jim McCarthy Read more →
Evolving a System
A complex system that works is invariably found to have evolved from a simple system that works . . . A complex system designed from scratch never works and cannot be patched up to make it work. — John Gall Read more →
Software Tips from Bjarne Stroustrup
Here are 38 tips from the designer of the C++ programming language. These in particular jumped out at me: [5] Don’t try technological fixes for sociological problems [8] Design processes to encourage feedback [9] Don’t confuse activity for progress [10] Don’t generalize beyond what is needed, what you have direct experience with, and what can be tested [19] Use existing systems as models, as inspiration, and as starting points [22] Design for change, focusing on flexibility, extensibility, portability, and reuse [27] Keep it small. Don’t add features “just in case” [29] Repeatedly review and refine both the design and the implementation [31] Experiment, analyse, and test as early as possible and as often as possible Read more →
You Have to Explain Something to a Computer
When you’re doing programming, you have to explain something to a computer, which is dumb. When you’re writing a document for a human being to understand, the human being will look at it and nod his head and say, “Yeah, this makes sense.” But there are all kinds of ambiguities and vagueness that you don’t realize until you try to put it into a computer. Then all of a sudden, almost every five minutes as you’re writing the code, a question comes up that wasn’t addressed in the specification. “What if this combination occurs?” It just didn’t occur to the person writing the design specification. When you’re faced with doing the implementation, a person who has been delegated the job of working from a design would have to say, “Well, hmm, I don’t know what the designer meant by this.” It’s so hard to do the design unless you’re faced… Read more →
Best and Worst Software Features of the Week
I was typing in Microsoft Word and I started a bulleted list with an item like this: Topic1. A sentence about Topic1. And another one. Then I hit the Enter key. What do you think happened? Not only did I get another bulleted list item, Word set the font to bold! So I typed this: Topic2. And as soon as I typed the period, Word turned bold off!! Not only did it figure out that I’m creating a bulleted list, it figured out that I’m starting each bullet with bold font, followed by a period, followed by more text in regular font, and it takes care of everything for me automatically! That’s pretty sophisticated. Compare that to Lotus Notes, which can’t even figure out when I hit Enter twice that I want to turn the bullets off! We use Notes at work and I swear to God, if I type… Read more →
Lotus Notes Sucks
I’m working with a company that uses Lotus Notes. It’s been more than 10 years since I’ve had to use Notes and it’s as bad as ever. It’s probably the worst piece of software ever released by a major company. The worst feature — well, it’s hard to pick a worst feature, but one of the worst features — because I have to deal with it dozens of times a day — is the way Notes makes me reply to email. I can’t just click Reply and start typing. When I click Reply, I get a dropdown list of options and have to select one: – Reply – Reply with History – Reply without Attachment(s) – Reply with Internet-Style History The godawful thing about this is that default options for email work 100 percent of the time. I always want to reply with history and without attachments, so why give… Read more →
Respect the Classics, Man: No Silver Bullet
This essay by Turing Award-winner Fred Brooks is almost 20 years old now. Sadly, the ideas on incremental development are still considered outside the mainstream in IT, which continues to favor the widely-discredited waterfall approach. Read more →
Requirements are Boring
You’re working on the requirements for Project X? Boring. You’ve got someone figuring out architecture for Project Y? Boring. The guys are designing Project Z? Boring. . . . Who has built something that their customer will certify is part of what they want? That’s interesting. Who has shipped something to their customer and the customer is using it? That’s very interesting. — Ron Jeffries Read more →
A Couple of Quotes on Software Design
I conclude that there are two ways of constructing a software design: One way is to make it so simple there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. A feature which is omitted can always be added later, when its design and its implications are well understood. A feature which is included before it is fully understood can never be removed later. — C. A. R. Hoare, Turing Award Lecture, 1980 Read more →