Here is how not to create your solution: get a team of 20 or 30 IT people. That is a proven path to incredible waste and failure. Just like Henry Ford’s people prior to the assembly line, our poor IT people are forced to use a process of extreme inefficiency and disastrous quality.
Instead, I use development principles that deliver a tenfold increase in efficiency and unprecedented quality. Together, we’ll walk through a few of the most important ones.
The first is team size. Remember, it may actually be a large solution, but it’s still not a large project. Large teams are great, for digging a tunnel. The more shovels the better. For corporate software, where communication is critical, too many people dramatically slow the project.
A team of eight has 28 lines of communication; a team of 120 has an astounding 7,140. The project is 255 times more complex! Even worse, more people means an increasing number of errors.
Since 1978, Quantitative Software Management (QSM) has led the IT industry in software metrics analysis. In 2005, they used metrics from 7,000 completed projects to analyze productivity and error rates and discovered the following statistics.
- A two-person team creates 40,000 lines of code in 600 days
- Adding 27 more people buys you 12 days
- And six times as many errors
In another study of 564 projects completed since 2002, 34 people completed 100,000 lines of code at a cost of $2.1 million. Cut the 34 down to four, and it takes just two weeks longer, with a cost savings of $1.84 million.
Don’t just believe me; books, articles, papers, and studies published for decades all come to the same conclusion. It does seem logical. Large software projects require a large team. It’s absolutely not the case. Small is beautiful for software development teams. In fact, if you have an IT project that has more than eight people or is planned to take more than a year, cancel it. Odds are very high it will fail.
Development Team Membership
If you’re wondering who needs to be on the development team, there are five responsibilities, and you will be surprised, only two have anything to do with IT.
- A business representative, with deep knowledge of your business who can speak for your CEO
- A documenter to write the story, in prose, no technical jargon — a journalist, who can explain in normal English what the solution does and how it works
- A tester, someone from your business area with deep knowledge of any old legacy software being replaced
- And finally, two IT responsibilities:
- A team leader with broad business experience and extensive software development experience
- A programmer, you can have as many as four of these
Now, this is important. Never exceed the maximum of eight, and don’t cut corners with quality and experience. It’s false economy to get only smart 22-year-olds. You need some grey hair.
What Tools to Use for Development
When software is done right, it is created in small steps called prototypes, that everyone can see and try. This includes not only the development team but also your senior management and business users. How do you pick the tools programmers will use to create the prototypes? I use the CEO’s method. Pick the one that gets you to done the quickest.
Don’t choose what everyone else uses, or whatever Microsoft is selling or even what your IT guys may want. There is only one criterion: the largest amount of software created in the shortest amount of time. Period.
With software for one-tenth the normal cost, standards don’t matter. Maintenance is history. When it’s obsolete, throw it away; create new software. The part of your IT budget that you spend on maintenance goes right to the bottom line.
Traditional tools like Java, Visual Basic, C++ are horrendous choices. They require translating business requirements into some logical procedure or structuring the requirements into some form of object methodology or modeling language or creating use cases, or a lot of other buzzwords that all add up to a lot of expense for zero business benefit. It’s tedious, labor intensive, error prone and requires pre-existing detailed specifications.
Rapid application development (RAD) tools are the only option to quickly create a working prototype and demonstrate it so that everyone can “see” what they’re getting. Spreadsheets miraculously simplify the creation and display of even the most-complex numerical problems. RAD performs the same miracle for business software. It’s a powerful concept. And when the prototype is complete, the solution is complete. The traditional systems’ development cycle is totally avoided, which is a tremendous boost in productivity.
Which RAD Platform is Best?
What specific RAD tool should you use? I am glad you asked that question. There’s one choice. eDeveloper from Magic Software Enterprises. It is so superior that I wouldn’t consider anything else. It’s the perfect balance between spreadsheets like speed and programming power.
Just to give you an idea of its awesome power, an international software developers’ competition, sponsored by Droege Computing, was held annually for several years in Durham, NC. Over 200 independent software developers from around the world competed for cash and prizes. The contest was to create a real-world application in 14 hours or less using specs provided at the start. They could use any development tool they wanted.
Contestants using eDeveloper won the competition five years in a row. In the final year, teams using eDeveloper, came in first, second, third, fourth, and fifth place. The competition was cancelled; people using other tools were no longer willing to compete. The rules changed every year at the request of competing tool vendors, but they could never come up with a way to unseat eDeveloper.
I just have one comment: why on earth would you ever use anything else?
About the Author
With over four decades of experience, Art Pennington is president of the Profit Research Institute, founder of four successful software companies, author, keynote speaker, holder of multiple patents, and creator of the “Profit Method” of business success.
