I just off the phone with an old High School chum. We got to talking about Bottom-Up Thinking as a way to set direction when a situation is unclear or changing too quickly. It was in the context of career, so I gave a lot of unsolicited advice … ‘natch.
However, it got me to thinking about all the messed up, and the few really great technical projects I’ve worked on. I think one of the most important things to do for every phase of any project is to decide if it is time to work Top-Down or Bottom-Up. I think for Software Design one must always work Bottom Up:
- To understand requirements clearly, it’s best to mock up, or prototype software to show stakeholders. Paper or a whiteboard is the place to start. It should be iterative with the prototypes getting fancier and the requirements firming up.
- Already know your requirements? Think again. Go back to step #1.
- Prototypes should always run and always be accessible, you never know who will get shown the proto and come up with the game changing idea.
- Think you know what will change the game? Think again. Go back to step #3.
- As soon as the ideas in the product firm up and the prototype represents them, it is time for User Interface (UX) testing. It is critical to design with the customer in mind asap.
- Think that silly users are not going to be able to understand the lofty ideas behind your story board, powerpoint, or web prototype? Think again. They get it better than you. After all, if they don’t understand it, why would they buy it? Back to step #5 with you.
- Prototypes become commercial software through a process of Re-factoring. Re-factoring changes incomplete, flaky or non-mission-critical components with stuff that is ready for prime time. The point is to be iterative, always have the software in working order, and develop tests+specs as you go along.
- Is the prototype technology too week and not suitable for heavy duty commercial use? Do you need some new language, tool, technique or paradigm to get your design implemented? Think again. All kinds of cheap technology powers critical systems the world over. Google started with a freaking Perl script. Elitism doesn’t make money. You got it, back to step #7.
- If you’ve gotten to this point. Ship It!
- Are you wondering if this is really ready for primetime? Maybe we need to make it run on a cloud, or have a real sysadmin, or advertise, or, or, I don’t know, do something else. Look, software is never done. It is much better to fail fast, and still be able to get back up, than sit around waiting for stars to line up. The real learning doesn’t start until the product ships. Back to step #9, and no excuses this time
Some folks today will call this Agile. But its been around a long time in engineering. Before the Internet, back when Pyramids were being built. Engineers noodle around too much, have lots of ideas, and tend to work top down. I am one, I know my type. The truth is, it really is a jungle out there. Work Bottom Up, in lots of little steps, up to survive Software Design.
Tags: agile, agile+software, agile+software+development, google, software+design