Keeping Track of Time – Part 1 – Recognizing the Problem

I have a confession to make.  Like many other software developers, my time estimates are seem to vary from real time.  Yes, giving accurate time estimates are a difficult task, especially ones that are over long extended periods of time.  Add on top of that time seems like an illusion at times, and you have a perfect storm for inaccuracy.  However one of the hallmarks of a good senior developer are good time estimates.  So what to do?

Well you have to fix that problem like any else.  First lets do some research on the problem:

From the looks of it, the problem consists of breaking down a project or a problem into reasonable amounts.  Then one can build time estimates on the design, implementation, integration and testing of the components.  Sounds easy, yes?  Not quite, but that is a skill that can be developed.  How?  Well track the components needed to perform a certain task, measure the time it takes to finish the task and finally do analysis on the results.  Sure you can do this by hand, with nothing more than a pen, paper and stopwatch.  However this is far too tedious and onerus when developing.  Humanity invented and built computers for tasks just like this.  Again after a bit of searching online I found the following tools:

Over the next couple of days and weeks, I will play with each tool and try to figure out which works for me.  Finally I will write about which worked out the best for me overall.

The Seven Sins of Software “Engineering”

On Monday, my class discussed about using software “engineer”for software writers. I naturally argued against it. My mother finished civil engineering, and I strongly believe in the elegance, timelessness and excellence of engineering. This morning, as I struggled with and later killed my groupware program over a dispute of syncing with my Palm, I solidified my stance against the idea of treating programmers as engineers. Here are seven reasons why programmers are NOT engineers.

Sin 1: Documentation
Most programmers do not document their code. Some of them say that code is self-evident, self-describing and self-documenting. Tell that to the poor souls trying to extend or maintain that glob of code you brain-dumped.

Now take a look at a blueprint of an engineer. What would happen if some of the measurements disappeared or someone forgot to label the room that holds the AC.

Sin 2: Testing
Programmers do not test their programs effectively. You wonder why your state-of-the-art PC keeps on crashing, as soon as you plugin that expensive computer card? Or just randomly? Testing frameworks, and concepts exist, but with the exception of a few individuals, no one does a decent job of testing. Whining about different configurations and different users does not help.

When an engineer designs a skyscraper, he/she needs with the whims of people, animals and nature. That is why after an earthquake, skyscrapers and bridges still stand in San Francisco.

Sin 3: Research
Programmers rarely research anything. They simply build a new toy program, and expect everyone to love it. They expect that they can experiment away, and deploy an untested and unthoughtout innovation.
Then surprise and dismay occurs when their innovation is unwanted and even hated.

In engineering, most innovations need a huge amount of research. Engineers need to design, test, and re-test ideas until they know they work. An engineering innovation never builds upon a brand new untested technology.

Sin 4: Meeting Requirements
“I’m the programmer. I know what my client really wants.” Wrong! This cocky behaviour of coding what the programmer wants, and not what is required happens way too often. User requirements often go unresearched or ignored. The users become upset at the developers. Company gets into trouble. And the programmers are forced to fix their mistakes.

Engineering anything revolves around meeting some need or requirement. These requirements and the challenge of meeting is at the heart of engineering. If the client wants a skyscraper in the form of a glass inverted cone, the engineer has to build it. But the engineer must find out, understand and then build according to the clients and the universe’s requirements.

Sin 5: People Skills
When things go horribly wrong, who gets the blame? If a building falls (without an obvious catastrophic uncontrollable reason), the engineer gets the blame. If a user’s data vanishes in a simple operation, the user gets blamed. Programmers always blame their clients of incompetence, even when a problem is caused by bad programming.

This behaviour goes beyond just blaming. Programmers ignore the advice and problems of their users, and keep their jobs. An engineer who does likewise, gets fired.

Sin 6: Reliability
Programmers suffer from terminal featuritis-o-philia. They program a new feature and continue on innovating, all when their program lacks stability of any form. User start believing that programs and computers have a mind of their own, with data disappearing, malware crippling systems and hardware crashing inexplicably.

Engineers strive for reliability. Ever building is designed to last the harassment of humans, nature and even “acts of God”. Every vehicle should not kill its occupant, unless a total, catastrophic disaster occurs. Wondering why to this day, the crash-proof operating system and program is still a dream? Reliability takes second step to “innovation” and “coolness” in the minds of developers.

Sin 7: Overall Cuteness
If there is a single profession I can think of when you can get away with unprofessional “coolness”, it is software development. Programmers love to use obscure shorthands, bizarre implementations and wacky ideas, even competing annually for the “cutest” piece of code.

Cuteness is a sign of un-professionalism, and often immaturity in the real world. A cute engineer is a starving engineer. A cute programmer is a thriving one. See why programmer’s can not become software “engineers”?

My rant ends now, and I know many will complain that I overexaggerated. True, there are some programmers that do not sin in the above ways. They are the exception. Most programmers pass themselves off as good, and still sin terribly along the way. An engineer who sins as such is a bad engineer, and rightly so. I claim that if programmers ever want to earn the distinction of software engineers, they need to raise their standards considerably higher.

Silent Running

Sorry for not writing sooner… The excuse is the overused “I didn’t have time to…”. That of course is not the real reason. While physical exhaustion is a factor, it was really because I was angry and upset. I find that writing comments in such a states often just makes things substantially worse.

However I will not be writing blogs as often as I would like to. This is because I am writing a novel nowadays. So I will concentrate on that for a while.

As for news, my Dad finally got a cellphone. I finally got a high speed broadband Internet connection and an excellent router to go with it. Yummy emerges from home. And Mom finally got a multifunctional printer, scanner and copier. And it looks more robust than the last one. So now I got a new (old tabletop one) scanner.

Met this guy Bart who is my age and goes to Waterloo University. He is studying Software Engineering and seems pretty cool. We talked and played three rounds of Legends. Naturally my Dad is giving me trouble about this. And all my explanations are inadequate for him. And now the laptop confescations and the “why do you have any non-educational games installed” are beginning anew. Sigh…