I'll admit that I'm a software developer and that I spend up to 9 hours a day in front of a computer terminal, but I don't think that it necessarily precludes me from the arena of self improvement. In fact, I have been trying to find ways in helping me to attain my full potential for a while now. And I also use software development methodologies as an aid!



For millennia the human race has been striving to better itself. Individuals try to make sense of complex issues and try to figure out how to get to where they want to be. In order to truly be happy, we must take our fanciful notions and find the best way to implement steps to take these notions and turn them into a final end result. You need a structured approach or else your end results will remain a scattered collection of beautiful, but useless, dreams. For a rather short time in our history, individuals have been trying to write complex software programs; trying to keep the ?end user? happy by writing programs that will fulfil their dreams - at least for a little while. Whilst one of these efforts is profound and the other less so, they do share similar strategies.

Writing millions of lines that actually do anything can only be done by using a structured approach. One of the first steps is to break down the task into a series of manageable steps. In IT parlance, this is called modularization. Most things in life are not one solid entity, but rather a heterogeneous collection of parts. So, when we look at any task we can ? and must ? break it down into its constituent parts. If we fail to do this then the task at hand will be to big deal with as a whole. Programmers identify the modules and write functions; real people identify the areas they need to work on in their personal life and go about devising schemes to improve them, or eliminate them.

In recent years computer chips have become more and more powerful. These chips are the brain of any computer; it is inside these tiny components that all user instructions are processed. As these processors have become faster and cheaper - allowing computers to have more than one chip - programmers have made use of something called asynchronous processing. In ancient times (about 10 to 15 years ago) a computer program would have to execute (implement) each of its modules (little tasks) one by one. When it executed a function, the main program would have to wait until the function had finished its job, before the main program could call the next function and so on. This worked but the process was slow. Nowadays we don't always have to do this. Instead we can call a function and not wait for it to finish before we call the next function. We call the function and let it do its business. We don't sit around worrying about it. We let it get on with things; it will tell us if it has any problems. The main thing is we can get on to the next task and complete the whole process much quicker using asynchronous processing.

So, what's asynchronous processing got to do with real life? Everything. Too many of us spend too much energy on things we shouldn't. If you've read anything on time-management, leadership or why successful people are successful, you'll have come across the word ?delegation?. Successful people are the planners, not the implementers. They have the big picture inside their head and they don't risk getting sidetracked. They delegate the smaller tasks to others. They delegate to someone (or something) and move on to the next task (which they will also probably delegate). They don't stop and wait for the task to be complete; they're too busy getting to where they want to be. Successful people run asynchronous systems.

The biggest step in software writing is probably ?reiterative development methodology?. In the bad old days there was (and still is) a methodology called SSADM. I won't bore you with the details, sufficed to say that this approach called for meticulous planning before any line of code was ever written. This approach can be successful but in too many cases it was a total disaster. Too much time was spent planning and not implementing. By the time the ?plan? was finalised, the goal posts had usually moved, so that by the time the coding was started the project was already hopelessly out-of-date. Aspirations as to what the software should do had changed. As a programmer, there is nothing more frustrating than to finish writing software that no likes or wants.

The reiterative approach allows software programmers to write a small, scaled down prototype. The ?end user? can take a look at it and make suggestion as to how it should be changed. The programmer then changes the application to what the user suggests and adds a ?little more meat? to the application. The ?end user? takes another look and makes more suggestions and the programmer makes the changes and adds yet more meat to the application. This cycle continues until the end user is happy with the application. The advantage with this approach is that the end user can constantly test out the application and if he doesn't like where it's going he can request that the application changes direction. Goal posts change so software needs to be flexible to accommodate this.

We all should use this reiterative approach: make changes to our lives, and then re-evaluate. Then make some more small changes and then re-evaluate. It can be a big mistake to invest all our energies into the ?big plan?. If the big plan doesn't get us to where we thought we wanted to be, we may not have the energy to make another ?big plan?. Life and dreams are fluid and so should our approach be.