I recently spoke with iRise, a developer of simulation software for software development, about its approach to improving software development. The resulting article has just been published on The BrainYard:
“Although I’d been through a classical IT education–discover the requirements, write a functional spec, get the software built, and then deal with the fallout–in my first company we made it a practice to build rapid prototypes based on a whiteboard discussion. We didn’t write functional specs; we sat around a table with a business team, talked about the work they did, drew some pictures on the whiteboard, and then went away and built a first iteration of the application. Then we’d come back the next day with the skeleton of the system and the core functionality, and discuss fit and alignment with the team again.
That first iteration was the specification. Based on the client being able to see what the words they’d said the day before looked like as software components, we would add or remove things in real time during the design meeting. I remember one client in New Zealand who hired me to build a suite of interconnected Lotus Notes applications. He and I did the design as described above, and within four weeks I had built (logging 80-hour weeks, mind you) 18 applications. When I asked why he hadn’t hired a local firm, he said dismissively, “Because they would have taken six weeks to write a functional specification. You built the system in four.”
Based on a recent conversation I had with iRise, a maker of simulation software for designing business software, the approach we took was ahead of the curve.“
Categories: Culture & Competency