Thursday, April 25, 2013

Will software engineers get to board Noah's Ark?

I recently watched the movie "2012" and that was the question that popped up in my head. For those who hasn't watched the movie yet, I recommend it.

Ok, since I am neither a very influential person in my field of work and I don't have the skills to navigate myself through massive earthquake in a car, nor a boss who happens to own a jet, my chance of being selected or forcing my way into the ark seems small, but what about the others?

In the scenario described in the movie (or the bible, whichever you prefer), there will be a massive destruction of the world and the only "thing" that is meant to survive is Noah's Ark along with whatever it manages to carry onboard. In the bible version, Noah took along all possible animal species (one male and one female) and plant seeds, and whoever who believed in his doom talk. Well, the world was a lot simpler back then. In a world as complicated as today, what else do we need?

Instead of just having Noah's family we may have to have representatives from all countries and races in the world, there are also far more species and books to carry, along with more tools and machines (Solar power I hope) that will speed up the rebuilding process. Of course there will now be books (or maybe ebook as they are far easier to carry) and art. There will also be a number of professionals each with expertise in their own field to either maintain the Ark during the waiting period and to direct the rebuilding process (Luckily the Ark in 2012 is far bigger than the one of Noah's). So what kinds of professionals do we need?

To name a few, we need farmers who can sustain the food supply, doctors to care for the sick, probably pharmacists to go along. Police to enforce order, but not much need for lawyer at this point. A bunch of renewable energy specialists would be good to quickly bring the power grid back up. Along with some telecom workers to bring up the corresponding telecom system. Without any of these there will be no need for IT specialists.

Though I think some people in the field of IT will need to be around in order to recreate the world, but not all field of IT is needed. If we are to look at all the softwares, hardwares that are designed and implemented today, 99.99% of them can easily be let go and we won't ever have to feel bad about it. It may even be a better idea to start from scratch. The rest can be stored in a revision control system, so specialists in that field would be good, to go along with some DBA. Now, to recreate all the bad hardwares and softwares that was let go, we need architects (the good ones of course, but that's not easy to define) who can direct the recreation once the rebuilding process starts. It would be nice to bring some business analysts to help defining the new batch of software so that they will be meeting the demands of the new world.

On the other hand, it is most likely that the general programmers will be waving the ark goodbye in tears as it is much lower cost to bring programming books. I am also not sure if we will need project managers as the space in the ark is precious (There can be an endless debate on that). As for the "luxury" systems that are good to have, how about all the BI, CRM, Sharepoint, Mobile App developers? Though I am a BI/CRM developer myself I really can't see the world to prioritize us.
So for us BI/CRM consultants who believe in the end of the world and would like to join the Ark, time to switch :)

Thursday, April 11, 2013

Documentations in a typical project

As mentioned in my previous post, one can learn a lot from creating documentations for a software projects, it challenges the writer to approach and view the software project from different perspective and thus allowing the writer to have a better understanding overall.

The following are some of the common documentations one would encounter in a software project:
Software Architecture Document (SAD):

The software architecture documents (SAD) gives the reader a complete overview of the entire software architecture, you may not know how each individual component works, or what it does, but at least you know what components exist and forms the whole architecture. This is the best way to understand the whole enterprise architecture.

Functional Specification:

The functional specification is often written by a business analyst who has been to a meeting with the customer and note down all the functional requirements by the customer. There are usually a function specification for each individual "boxes" in the SAD with each describing the functionality in full detail. A good guidance of writing one would be thinking in terms of user cases to outline what the customer is trying to achieve and thus arriving to the list of functionality requirements of the boxes.

Technical Specification:

The functional specification is then passed down to the lead developer who have several years of development experience along with some domain knowledge to translate into the technical specification. The finished product would then be the "bible" where the developers implement the solution strictly based on this document. In the document, usually the data objects, the manipulation of such objects and the presentation of the objects would be listed in detail. In a test driven design approach, one can write out the unit tests based on the functional specification as a staring point.

Test Cases:

As the implementation phase is coming to the end and the test phase approaches, the test team (a true luxury) will be getting ready to test the application. Together with the business analyst, lead developer a plan of how to test the application will be made and the test case document will be written. The test cases are usually based on the functional specification and need to cover all the use cases. Then the boundry cases need to be tested to make sure they are handled in the desired manner.

Deployment Guide/User Manual:

Once the implementation is completed and the project is entering the test phase awaiting delivery. It is time to start preparing the deployment guide, and the user manual. Some of the non specified behaviors would be described in this document to guide the user. Deployment guide would be required should the customer ever need to redeploy the system to a new server in the future. In the ideal case, the system works exactly the same as expected and no one will ever need to pull out the user manual. Well, when did the world ever function in the ideal way?