As part of the Architecture definition for a project I'm working on, I have been preparing a cost estimate. The idea is that the client wants to know if they need to tender the project out to third parties, or whether it can be developed in house by the shared central IT department, used by several business units. In a meeting with the client today I presented my initial estimates. Me: "So as you can see, the upper cost will be 820 thousand CHF." Business Unit Project Manager: "Hold it there. You do realise there is a cost threshold at 600 thousand right?! Above that, we have to tender the project out, and that will add a delay of two months!" Me: "Sure. In the pre study, there is a project plan showing that an initial estimate places the work at around a million CHF. And in that study, it allows time for the tendering process. But good news, it shouldn't cost as much as a million..." Business Unit Project Manager: "Can't you somehow reduce the costs? You need to bring it down a little more...We are already running late." At this point, my unprofessional answer (which I managed to hold in) was along the lines of "OK. Instead of me wasting my time doing a real estimate, just tell me how much you want it to cost, or rather how much less you want it to cost than your boss already thinks it will, based on the pre study.…
Category: Uncategorised
Gathering Evidence
While working on a previous project, before I had a blog, I remember an incident with a particular boss at a company which thrived on a blame culture. No one cared if software was late or crap. All they cared about was whether another department was to blame. So once we screwed up on a project and his response was "Can't you find an email showing its the customers fault?". In this case, the answer was "No, it was our fault. I screwed up and misread the requirements." Being a good boss, he didn't want to shit on me. "OK, but surely you can find an email that shows its the customers fault? Thats all I need to copy to his boss." He didn't care about the impact on the business. Didn't want me working over time to fix the problem. Didn't want me to accept responsibility for the problem. He just wanted to blame some other department for the problem. And this was the way he worked project after project. Find evidence. Copy the head of the other department. Threaten to escalate... He wasn't alone either. Every department worked in the same way. No one had accountability. It lead to people being scared to make mistakes. Perhaps that was why the company was a market leader? But it wasn't a very nice place to work.
SLOC
SLOC is "Software lines of code" and is an old measure of productivity when taken as lines of code written per day. There is lots of debate about its use, whether its good etc. But when comparing like for like, it should give valid results. I once worked out that there were something like 20 lines of code a day developed in EAI at my last client (with say 300,000 lines of code in total). We said it wasn't too bad, compared to the old days of OS development quoted as around 5 LOC per day... I'm reviewing a project here with around 160,000 LOC (thats an assumption that the GUI is the same as the back end, which is around 82,000 LOC). It was developed in 5 months over 820 man days. That makes around 200 LOC a day, so ten times more quickly developed than on the EAI project. It includes generated code, but probably as much as the EAI tool gives you, showing that if you want to build an SOA, that old EAI tool is slow to develop with. I then took a look at the maxant demo I did. It has around 36,000 LOC (again an assumption that the GUI has the same amount of code as the back end which is around 18,000 lines), and I did that in around 70 man days. So that's around 500 LOC a day. Both the project I'm now reviewing and the maxant demo have 150 lines per…
Cowboys
Today I moved to a new part of the building that has hot desks. "Choose the desk you want today" I was told.. Two minutes later, I was trying to find a network cable for my laptop. There are two machines sitting on the next desk, so I thought I could take one from there. but as they were on, I asked about it. "NO! They are production machines!!" came the horrored response. Bloody amateurs. I'm guessing one is the failover replication of the other or something good like that. The user used to log into them is called "CISOnline Update" (its a windows box, so you can see) - apparently they are an update of the system used by the call center and business partners to book shipments here (one of the biggest companies in the country I might add), probably rolled out to just some beta users or something... can you imagine it? I put a sign on them saying "Production Machines - do not turn off or disconnect". Wonder if that will help? Probably not, since now everyone know where to go to corrupt production, or steal commercially confidential data. *UPDATE* Network man came along the other day to patch in some more switches and didn't have a long enough cable. "Aha, I will take one of these..." he said looking at the ones sticking out the back of the production machines. "No!" I told him and explained. He didn't look surprised. Perhaps this is all a…
JMS API
Been applying for contracts and got a phone call from an agent asking about my skills. "You have JMS skills I can see from your CV, but we are looking for 'JMS API'" she said. I went on to explain that API stood for Application Programming Interface, and that I had those skills. In fact, to have JMS skills as a developer, it means you have the API skills. They go hand in hand. "I see. OK, I will check with my colleague and we will be in touch". Why do recruitment agents screw around with us? They haven't been back in touch, and from her tone I could tell she wasn't interested, even though all my other skills matched quite well. It's like a salesman selling cars, but not knowing that PAS stands for Power Assisted Steering, or not knowing that it means that its related to the steering wheel. Come on, how do these guys get jobs!?
New Project
Last Friday, I finished my project with the current client, after over two years. It's now in the capable hands of IBM India. Hopefully things go well for them. Ah, no, hopefully they call me back in a few months, at which stage I will double my charge rate!! So my next short task is to do a study on open source J2EE Enterprise Service Bus products. Ever used one, heard a report about one, etc., then please get in touch. So, on Friday, a friend sent me the following Dilbert, which was quite apt.
Code Ants
We all know about the term 'Code Monkey' which refers to junior developers... Well, I'm calling my ants 'Code Ants'! Anyway, slight problem with them - I put hand cream on the edge of their tupperware home, so that if they tried to venture out, they would think twice and wouldn't drown. Sadly, the cream has dried out, and more and more are going over the edge, losing grip and drowning! Lessons Learned for Project Management: Don't allow your code ants boundaries to become unclear! Give them the slightest opportunity to get off the project, they will take it, even at the cost of their own life. Keep reinforcing their boundaries so they know their place.
Ant Farm
At the weekend, I was in the park playing with my son and he was intrigued by the beetles and ants. So we popped home, picked up some tupperware and a spoon and went back to get some ants to have our very own ant farm! They are in a tupperware container within a bath, so that if they do climb over the edge they won't be able to escape and scare my wife out of the house. See below for what it looks like. Anyway, its a bit like a fish tank in that its very relaxing to watch them building and feeding, etc. As I was watching them pulling a pupa from where I had tossed it out of the original tupperware container into their new home, it got me thinking. They can't see the bigger picture, yet they make a good job in getting there in the end... For example, they were pulling at this poor thing to try and get it over a blade of grass, but couldn't. So they went left, the long way round. They should have gone right! But there was no one there to guide them along the way. In the end however, they got to where they were going. Now, having turned left, I can't say that they didn't change their plans and continue going that way, because at this stage, there was no established ant hill, so they were just looking to see where everyone else was going I guess.…
Cartoon
This is one of my favourite software related cartoons. Unfortunately I don't know where it came from, so I cannot give credit to the originator. Sorry! (scroll right down to the bottom of the page, since the blog software is trying to be clever...)
Cannibals
Apparently a big off shore IT firm is desperately hiring anyone it can, to fulfil its contractual obligations and as a last resort to find resources considers hiring some cannibals. "Look, we will hire you, but we will NOT tolerate you eating any other staff members. Is that understood?" asked the HR manager to the cannibal leader. He agreed and shortly afterwards, him and his tribe get to work. Six weeks later the HR manager learns that a techie has gone missing and runs to the cannibal chief. "What have you done?! I explicitly told you, no eating the staff! You are ALL fired!" The chief turns to his tribe and asks "Who the hell ate the programmer? We agreed to only eat the managers. We've been doing that for 6 weeks and no one noticed..."
