Category Archives: Project Management

Web Software Devs – Don’t build a Galloping Gertie

Woke up today morning (afternoon) to the news that Microsoft Store India’s site had been hacked and it’s plain text user passwords put up for everyone’s benefit!

Now I don’t approve of that action, but I am really appalled and flabbergasted that in 2012 we still have databases that have plain text password stored.

Being a staunch MS loyalist, first thing I did was lookup the default aspnetdb which any n00b developer would use as the starting point. Thankfully even the sample aspnetdb does not store passwords in plain text. That made me even more mad. So the danged n00b who did it, didn’t know/care about the out-of-the-box security framework available. For me this is a bloody failure of the entire s/w development process, the developer, the QA and the gawd-danged manager who managed this freaking project!!!

Going back to the title of the article if you don’t know what the Galloping Gertie was, please check this out. If your site gets hacked (and I am not asking you to build an un-hackable site just don’t present it on a platter), and it turns out your users’ email and password were compromised and they were in plain text, your creation just collapsed like the Galloping Gertie. That single civil engineering ‘mistake’ is still upheld as how not to design a suspension bridge. It happened in the 1940’s and since then there have rarely been such spectacular bridge failures. But every second month we hear how a high profile site getting hacked and plain text passwords getting dumped for everyone to see. We don’t just seem to learn from our mistakes. Instead we crib, we crib about how little time we have to build/qa/test/gather requirements or how it is the platform’s fault blah blah blah! It’s always someone else’s mistake! STOP passing the buck it’s NOT someone else’s fault!!!

Sometime back I was reading in a blog (don’t remember the exactly where probably Hanselminutes), where it was said, health of a software development process is judged by how well the management knows about the code. Yes, you heard that right, the code. Unfortunately in the last twelve years I have seen people in software development, so eager to become managers so that they don’t have to look at code, that’s its sad! It’s beyond sad actually. When you have managers who don’t care about code, you have code that’s not the best it could have been because at the lowest level either the developer is too frustrated with writing the correct code or doesn’t care because they are in a hurry to become a manager too!!!

This happened closely in heel of the Path fiasco,  where a startup thought it was okay to upload the user’s entire address-book without asking and then pretended that it was a mistake. Free web, leaching out information from you in form of cookies was bad enough, now it is claimed that if a framework doesn’t stop me from reading other’s personal info it is an ‘industry-best-practice’ WTF!!! That’s like saying I built a virus because the OS allowed me to and I should be a hero!!!

Software Devs, it’s time we grew up and acted like grown ups. Take security and personal information more seriously. Be up-front about your actions to your end users, else software as a branch of engineering will be scarred irreparably!!!

Update June 6, 2012: It would seem another ‘Galloping Gertie’ has collapsed. LinkedIn‘s database got compromised and revealed plaintext passwords. I guess going forth I’ll just maintain this as a ‘dis-honor roll’ of sites getting hacked and being found to contain plaintext passwords. BTW according to their blog  they have ‘recently’ upgraded to salted hash passwords!

Tagged , , ,

Thou shalt take the fall – you novice C-PM

August 21, 2008.

Well, what can I say, it had to happen and it happened…

In my last post I had mentioned how a C-PM (Coder turned Project Manager) bungled his first project. One thing he was sure that he loved his team and his team understood why they were putting in the efforts they were putting… Alas…
When the project was nearing it’s end three people in the team dropped papers (resigned). In software industry churn in a team is an acceptable fact of life, but 60% of the team resigning sends alarm bells ringing all over the place… Hence starts the process of negotiations and re-conciliation and so on, in the end on my recommendation one person was retained by giving as much incentives as possible. Two people I had to let go because I felt they were not up to the mark. The person who was retained little do they know why they were offered those incentives. They believe that it’s their performance… haa haa…

Cut to my appraisal meeting: Face to face with my boss he presents me with the appraisal letter in an envelope, I set it aside and I tell him I need to have feedback on my performance. Little do I know I am in for the shock of my life…

With a project having overrun 400% with respect to time you don’t expect bouquets from your boss. I don’t know what I was expecting at that point but the following shook the roots of some of the things I believed in:

I was accused of not following processes. Not only by boss but according to him also my team members who had resigned said so during their exit interviews (including the one that was retained on my recommendation). Fact is I had minimal processes so why should I be shocked when someone says so?

Rewind: beginning of the project… It was my boss who has said, do what you want, I don’t want to impose strict processes etc etc etc, get the project successful… well it wasn’t successful so I guess all that support also gets washed away.

The minimal processes I had were:
1. Write good code. (if you can call that a process).
2. Following naming conventions.
3. Check in code on time.
4. Test your own work.
What did I get?
1. The code that was written by the so called seniors of the project was as neat as a pile of poo.
2. Naming conventions? What are they?
3. Code checkins? Well it works for me so why the hell bother about anything else.
4. “I changed two lines today and they work, why should I bother about the remaining 10K lines of code?”

So much so for processes. Next I was accused of incorrect estimations and lack of planning.
I would really like to meet that person who can estimate a software project correctly and can factor in client whims, disastrous code base, resource incompetence, company profit margins and ridiculous deadlines.
Next is planning. So what does that entail? Assumptions? I guess…

September 5, 2008

Note: I had started this piece as a vent to my fustration some time back, and then I had stopped. A lot of water has passed under the bridge since then… Still publishing it… I am sure C-PMs like me will have something of a takeaway from it. Least they can do it not make the mistakes I made…


What do you do with a failed Project Manager!

Make him the production support guy!!!

That’s the message I got from my manager shortly before I left India.

Couple of months back I had blogged about how a Coder turned Project Manager bungles his way. Well it was biographical! Needless to say once the project failed I lost all support from everywhere including my immediate boss and my team who blamed me for everything. No complaints there I did commit a big bunch of goof-ups. So in the end I was told I would now be responsible for the project that I had bungled from the client side and the people to whom we delivered the botched application would now look up to me to support it as it struggles to live up to user expectations.

No complaints now, this is like getting back into familiar territory. After all I am best friends with code. I understand them and they understand me and we don’t blame each other for failures. We simply work in tandem to improve things. Starting monday September 8th it will be just me and the code (and some not very happy users)…


(Sorry folks, for sometime in future you won’t be hearing about me trying to become a project manager any more)

Tagged ,

Coder as a Project Manager – destined to fail?

Project Management as seen by an ‘Accidental Project Manager’.

A little Background to start off with – I’ve been a ‘software guy’ since the past 15+ years, ever since my Dad got a 8086 based PC way back in 1991-92. Since then the sole aim in life had been to ‘master’ Computer Science. It’s something I took to heart. Scrambled through a Bachelor’s Degree in the year 2000 and since then have been a ‘programmer’.

Eight years on I still prefer to write code. Much to the disconcertion of all my bosses, I staunchly refused to wear the dreaded ‘Project Manager’ hat. Why? Some of the reasons are:

1. As a die hard coder I believe it is my religion to write near perfect code in absolute impossible timelines.
2. ‘Project Management’ only seems like an overhead with host of things that seemingly have NOTHING to do with final outcome – Clean pristine code for an application that works like a charm.
3. All project managers seem to have absolutely infalliable ability to frustrate ‘real’ coders with incessant requests for updates, process compliance so on and so forth.
4. Project Managers main job seems to start off projects invariably on the wrong footing and struggle the rest of time to set the wrong right but ending up in many more goof-ups.
5. Real Project Managers never seem to get blamed for anything. It’s always the coder who screws up.

Such were my impression about project managers when finally one fine day my Boss called me and said, ‘Sumit, time’s up. Now is when you get to see the other side of the pasture. Here is a project for you – Go Manage it. Do whatever it takes, get it successful.’

The Coder vs The Project Manager
A coder is an eternal optimist. Everything is doable in a software engineering world for a coder. For a project manager nothing is doable unless justified with a proof of concept and 80% accurate estimation of time (every company has a 20% margin of error in time estimations).

Coding output is never a linear function. Someday you do spend 20% of time doing 80% of the work and on other days you spend 80% of time doing 20% of the task. For a project manager everything has be moulded into a linear function of progress. Unless tracked on a daily basis progress becomes unpredictable and unmanageable leading to failures invariably. The more paranoid ones try to manage it on an hourly or half-hourly basis.

Coding is all about passion, bonding, camaraderie and the love of doing it. Project management is the cold world of facts, figures and numbers. Only criteria of measurement is if the project is green/amber or red. Do whatever it takes to keep things in green; plan to the minutest details, be compassionate, be brute, be reasonable, be un-reasonable, coax, cajole, threaten, whatever it takes…

Coder as a Project Manager
Given the above differences when a coder is first given chance to manage projects their approach is a hotch-potch, mish-mash of above that results in an optimistic guy who overlooks estimation because he (or she) ‘feels’ that the ‘finish’ is just-round-the-corner; contingency management is all about one ‘nightout’ with unlimited supply of coffee; for larger issues – like a week’s offset can be easily restored by spending 24 hours over the weekend; and broken functionality can be ‘fixed easily’.

Coder as a Project Manager is a special breed, let me call them C-PMs for easy reference.

Life of a C-PM
C-PMs are almost always Accidental PMs. They just happen to be the ‘reasonably equipped’ person at the wrong place at the wrong time (right place at the right time?). Hence most common characteristics of these people are:
1. They are good at what they are supposed to do. So for a C-PM he/she is definitely a good coder.
2. They communicate well (speak 60-70% grammatically correct English).
3. They are confident and willing to take up challenges.
4. They are reasonably popular among their peers (at least till they are coders).

Things however start to change rapidly as their first project starts off and gathers momentum. Minor issues pile up and slippages increase from days to weeks. Suddenly deadlines are tomorrow and the world seems to fall apart.

Where does a C-PM bungle
If we go back to the characteristics of a C-PM it is obvious why they fail as Project Managers:

1. Optimisim always clouds reality. Much as they would like to blow the whistile, that lingering hope it will be fixed/done pretty much shoots down realistic tracking of progress.

2. Non lineraity of development activity almost always results in estimations that consider the 20% of time needed to do 80% of the stuff but misses out on the 80% time needed to do 20% of the stuff. In the end that 20% of remaining stuff becomes the deciding factor between a successful and an unsuccessful project.

3. Camraderie often prevent hard decisions like reprimands for missing timelines or quality of work. That combined with Optimism results in a cocktail that leads to disaster.

Will the C-PM ever manage a project successfully?
Not unless he imbibes qualities of a project manger and consciously suppresses the urges that result out of ‘addiction to coding’.

Watch this space as a C-PM struggles to get to terms with the world of Project Management and like every other C-PM worth his salt, try to come up with a model that combines Project Management with Good Coding…

%d bloggers like this: