Forbes Magazine's article Saving Software from Itself talks about the problems with software construction. It recommends catching the problems at the assembly line. From our perspective as programmers looking at the industry from the inside, we can tell you there is no assembly line. It's more like trying to build something out of mud.

Most software starts out with a vague understanding of requirements. Programmers want to begin programming as soon as possible. Any written technical specifications are difficult for the users to understand. In most cases, the technical documentation is not even a good indication of what work is to be done. Most developers are not permitted to work remotely because there is no way to keep everyone on the same page.

After a few weeks the results are not what the customer expected. I sat in on one meeting where a couple of programmers spent 3 months together designing something I felt would be very awkward to use. When they proudly demonstrated their efforts, the users had to try to be diplomatic about how they would be unable to use the product. Programmers generally build systems that work, without considering how to help the user work better.

We take a different approach. We call it tutorial-based design. We first produce a tutorial based on user workflows. Many programmers cannot do this at all. Some feel it is impossible to get the level of detail right. We can do this because of the depth of our experience in different industries. We know what works and what doesn't. The tutorial is built with lots of user input, just like when someone starts to design a new home. It becomes a blueprint for the construction, but it also incorporates conceptions of the appearance of the screens. It shows sequences of screen interactions that correspond to the user workflows. The user can start to actually contribute useful feedback before development begins. Having been involved in so many development projects, we've stepped way back and come up with a development Strategy that can be applied to most data entry applications!

Once everyone really knows what will be built, it becomes easier to coordinate team efforts. Customers, business analysts and users know exactly what to expect. There are no surprises. Testers can begin writing test scripts in anticipation of completion. If a design change occurs, everyone can adapt, relatively easily.

Bugs are reduced, but when they do happen, all anyone has to do is refer to a section of the tutorial to aid in demonstrating the problem. Two things then happen. The tutorial is changed to propose any repair and then the repair is made.

Save yourself from these problems. Contact us to see how much more productive development can be.