Making Custom Applications Affordable

As any software project manager can tell you that the cost of software is not the technology but the cost of development. That directly relates to professional man hours. In a book written many many years ago called "The Mythical Man Month" (ref), we were informed that building a brick wall has nothing in common with building a software program.

A Brick Wall Build as a Software Development Analogy

If it takes one worker one month to build a brick wall it is in theory possible for two workers to build that same wall in two weeks. In actual practice it may take less than those two theoretical weeks depending on the level of communication between the two workers and their individual expertise. This idea is common sense to most people. If you want the wall in one week then you use four workers.

When it comes to the process involved in producing a software program it becomes much more complex as you add "workers". To continue the use of the analogy if one worker at the brick wall makes a change in the way he is laying the bricks so everyone else has to make adjustments to their methods and all have to go back and rebuild the portion of the wall attributed to their responsibility.

The "two worker" brick wall analogy is different from a software project in another way. With the brick wall project the work can divided into responsibilities such as bring supplies for a lower experience level worker and laying the brick to the wall for the more experienced worker. This just can't be done in a software project. Each worker is building a portion of the project and the edges of each of their "project walls" must fit exactly with the other pieces. Off a little bit here it will not work correctly. It might even fail to work at all.

Projects of this type are run by a management entity that oversees production and makes sure the pieces fit by testing them all together on a scheduled basis. The management directs time frames to bring the pieces into what is called a clear point. This clear point is best described as a period of time when all development stops and the pieces are tested to make sure they work together even though they may not yet provide the desired results. All of this activity of pieces being brought together for testing is required so as to not come to the end of the project and have nothing working together.

To insure the pieces are going along in a fashion where they are doing the right work requires code reviews and testing in a "test bed". The test bed is a piece of software especially written for that one piece of the whole project. Each piece has it's own test bed. Each one is written for that one piece. It may be this is where a second set of developers may work just to insure these test beds are congruent with the actual specifications of the project and those project plans that were laid out in advance by the management entity.

The Software Development Plan

The projects plans laid out by the management were derived from what is usually called a Software Requirement Specification. The construction of this document is very very detailed and can take a great bit if time to complete. One reason for the detail is that once the project is started any change would require everyone to back and start over, almost! They would at least have to revisit every area of the software project to verify that the code does not interfere with the new changes. The other reason for the detail is that this will be the document that the client signs off on before the project begins. If the client made a mistake in accepting the Software Requirement Specification they are informed in the contract that they will pay for it later.

Now we all know that businesses change their policies procedures and focus. The larger companies take more time to make a change and smaller companies are more agile in their responses to a new opportunity. It is this difference that makes business in an open economy real challenging. A business will work hard, its employees will work hard all to make the business grow. This very growth, the company's mere size can put them into a position of not being able to take a freshly identified advantage when that new idea arrives in their industry.

To set a Software Requirement Specification, then wait three to six months with no changes to a document that defines the very process and policies of a company and expect there to be no changes in the companies process and policies is almost naive. Then to pay double time for the corrections that might ensue is frightening to most small business owners.

The Agile Method for Software Development a Better Way

Any and all of this has happened, many times over during the past decades, and is happening right now to hundreds of businesses. I really believe that it is unnecessary. Newer development methods are in practice today. We have used an Agile Development method for many years now. I can best describe it as a "blue collar" Development Method.

If you were to decide to renovate an old automobile it would involve a number of steps but you may not have all of the steps lined up and planned. You would have a fairly accurate idea in your head of what you wanted the results to look like.

You would then find a number of junk or older cars which you might want to work on. Once you decide on which junk car to start with you could then located a body shop, an engine shop, breaks and suspension shop that would be willing to do the work. Still you don't have a complete plan but you still have the idea.

As you can, most likely, tell where I am going with this analogy I will stop here. With the Agile Development Model and Methods you do not have to have everything written down in advance. You wait for the first cycle to be completed and you then meet with the development team and show them where to make changes. You improve the ideas for your company with an actual working piece of software in front of you. The comments are tangible. They are not just ideas conveyed by talking but shown and discussed against a real piece of software.

At the time of the first review the development team is ready to make changes. In fact they are expecting to make changes. When the project has to be changed it is done in small regular increments. Comparatively speaking this is not much change when compared to the three to six months of accumulative changes that could be experienced in the examples above. Plus the expense of having to produce an Software Requirement Specification is just not part of the cost.

Software Development Tools

All developers use languages and tools to work with those languages. Most are described as an IDE (Integrated Development Environment). Not all development tools are built to match this fast direction changing development called Agile Development. Some even prevent this type of model from working at all. The one we have found to be the greatest fit with the Agile Development Model is Clarion. I won't go into it here as this subject is covered in other places at our site and numerous papers already on the Internet. A lot of this has to do with the data information repository called a dictionary. Another big factor are the language code generators called templates. The two, together, make for a power house of Agile Development. Add to this mix hundreds of third party template sets for anything from automated database management to network communications and web applications well you should be getting the picture I am painting.

Another factor is the ability of using an open source project called "Clarion to Java" that focuses on the code from Clarion. It will translate all of the standard Clarion code into Java code. This will allow most of a project to be translated into Java with very little rewrite. This development language translation allows the applications to be placed onto Smart Phones, Macintosh™ and Linux™ platforms thereby moving the working computers off of Windows™. We can use the speed and flexibility to write an application for Windows™ and then translate it for other platforms without having to rewrite the entire project. This saves development time and client cost.

Drupal™ has become our 'de facto' CMS (Content Management System) for Agile Development while creating Web applications. It has a great deal of the functionality already built in and a great deal of additional functionality available as contributed modules. The development is very easy to supplement with newly developed modules too. We have mixed both Clarion™ and its translations with Drupal™ into what is called a "mash-up" in the business. Giving our clients the technology they need to reach, using performance software solutions, to every corner of the Web and to every member of their company is the benefit we bring. It does not cost you anything but a few minutes of your time.

Just call us at our phone number 770-564-8899 or contact us to learn more about our services.