One thing that getting older gives you is perspective. What excites youth is looking ahead at the infinite possibilities the future promises. I think that maybe wisdom comes from combining the two. With infinite possible paths forward, it’s useful to occasionally look back to see what’s worked, what hasn’t, and why.
I’m involved in a big software project – BeLooped – that has incredible potential and yet has not progressed at a speed anywhere near what I would like. The other evening, I sat back and pondered why some projects I’ve worked on have succeeded while others have not. I concluded that a big factor is the development approach.
I guess another thing age gives you is enough experiences that you see analogies. So I’m going to use one. I’m also involved in a CoHousing project: CompassCoHousing.com and I’m part of that project’s development team. This will be a 40-unit facility. It was after we found land to build on that the real fun began.
We hired a geotech engineer to do soil samples to make sure we’ll be building on a firm foundation. We’ve consulted with Fortis as they have a large pipeline running through a portion of the property. We’ve had multiple meetings with Langley Township staff regarding road access, height restrictions, upcoming environmental bylaws and far more. We’ve shown Canada Post our plans, to learn where they need to access for mail delivery. We brought in a cohousing expert all the way from California at least 3 times to give advice on the overall design (he didn’t seem to understand that it rains here, though). We’ve hired a building architect (turns out they do much more than just draw pretty pictures) and a landscape architect. We’ve recently selected a mechanical engineer and will also need a communications team (internet/phone), a security consultant, a ventilation specialist… the list goes on and on and on.
Actual construction is going to take very little time compared to the “prep work”. And you know what? A software project needs the same level of diligence. Gone are the days of “cowboy coding”, where one good programmer could hold everything in their head.
What it takes to create a build or commercial grade software is: a good plan. That old adage “failure to plan is planning to fail” is absolutely true. Here are three of my pre-coding requirements:
- a product philosophy — the big vision of what you’re building and what differentiates it (the “what”), how it will improve the world, and why you in particular want to build it in the first place (the “why”). It better be compelling, because all projects take longer than you think they will. Plus, you need buy-in from the developers.
- a manual — you must must must must write the operating manual before the software is built. People may tell you that you’re wasting their time, coders will tell you that they “think in code” and that it’s more efficient to just start coding. They’re full of the waste products from a bull’s breakfast and lunch.
I assure you that not writing a manual — or having staff that don’t read it — is the single biggest mistake you can make.
If you cannot easily and succinctly describe how your software works, then the design is wrong. And despite what coders will tell you, they really are in love with their code and don’t want to throw it away and start over. The earlier you catch design flaws, the higher the chance of success. Writing a manual forces better design.
The purpose of the manual is to test your design. Again: if you can’t explain it in terms simple enough that your grandmother can understand then the software will be too hard for normal humans to operate. - low-res mockups — I do these on 3 x 5 cards, and they’re hand-written. I draw on the plain white side of the card, and write any explanations on the lined side. That gives me approximately the information density of a smartphone screen.
I then number the cards and for each control I write the number of the card that shows what happens if that control is accessed. This allows me to physically play with the “flow” of running the program. By laying the cards out on a flat surface, you can also see the depth of what it takes to get to any particular function.
You can do pixel-perfect design later to show to investors and the like, but nothing beats a pencil and a stack of 3 x 5 cards when it comes to rapid turnaround. It’s easier emotionally to throw away a card than to change code.
The thing is: when GUI interfaces came along, it started a trend where marketers advertised that no manual was needed. And developers believed the marketing hype. I can see why: that marketing message speaks to the ego of the average developer.
Developers like to believe that their design is clear enough for “users” to automaticaly figure things out. This is demonstrably false. It’s “form over function” — just because it’s pretty doesn’t mean it’s easier to use!
Then there’s efficiency: I was in the education administration industry for a long time, and there were scads of school admin products that were pretty easy to understand, but were inefficient for the school staff that had to use them. The best admin system that I ever saw had on-screen menus with up to 9 single-digit choices. On first use, it seemed old-fashioned and kind of blah. But the secretaries caught on real quick — 1-5-2 might go down 3 layers in a hierarchy to exactly where they wanted to enter or view certain data. To a first-time user, it seemed inefficient, but in short order the navigation literally became muscle memory and couldn’t be beat.
Naturally, this product lost out to sexier (and much slower) GUI-based systems.
While a flashy GUI UX impresses the people who make purchasing decisions, it’s not always what makes the people who USE the software more efficient. Unfortunately, those people are a few layers down in the hierarchy, which is we’re not seeing the productivity improvements that are promised.
You’re writing the manual as a guide for the coders, just as architectural drawings are for the builders, not the tenants/owners. If you can’t describe it succinctly, the design is bad. So before you start your next project, save yourself time by writing the damn manual!
And if you don’t believe me: hire a team of construction workers to build a 40-unit CoHousing project. Tell them start building today, without any architectural drawings and see how well that goes…
It will be entertaining for others to watch, if nothing else.