Tag Archives: Project Management Failure

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!

Advertisements
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…

Tagged
%d bloggers like this: