On Tue, May 26, 2015 at 1:16 AM, Dhiruj Rambaran <dhiruj_at_shoponline.mu>
wrote:
>
> On 25/05/2015 20:32, Vy-Shane Sin Fat wrote:
>
> On Mon, May 25, 2015 at 5:19 PM, Dhiruj Rambaran <dhiruj_at_shoponline.mu>
> wrote:
>
>> Academically we like to stick to standards etc.. .but in real world
>> business, it's all about "who pays your salary"?
>>
>
> Civil and mechanical engineers are lucky because they can point to the
> laws of physics and say - "Sorry, we can't compromise on this
> specification. Not if you want the building to stand 100km/hr winds.
> However, we can remove five floors and that will bring the budget down."
>
> With software we often deal with intangibles. A good engineer knows what
> can be sacrificed and what shouldn't be. And a smart business listens to
> its experts.
>
> *"And a smart business listens to its experts"..... I think this says it
> all. It all depends if you're dealing with a smart business or not.*
>
Well, we need to find ways to deal with the external budget and deadline
pressures. If we cut corners it sets a dangerous precedent for the project
[1]. Then, two years down the track we're looking at a rewrite because the
software is sinking under its own weight. How does that serve the client's
needs? I've seen this scenario play out time and time again:
1. A new client approaches the company. They aren't happy with their
current supplier because things are always taking too long to implement and
it's costing them too much money. New features take ages to build and the
software is constantly breaking. The relationship with their supplier has
reached breaking point. The client gives up. Let's start again from scratch.
2. The project starts, everything is beautiful! It's a greenfield project!
The client loves us!
3. Scope creeps, or simply, the problem domain only becomes clearer once
work has begun. Subtleties surface, assumptions are proven wrong. This is
the nature of the beast. That's normal. But this is rarely handled in a way
that avoids what happens next.
4. The deadline slips. The client is concerned. But we promise we'll make
up the lost time!
5. The deadline slips again. The client isn't happy. The account manager
isn't happy. The project manager isn't happy. The engineers are told to get
their fingers out.
6. The deadline slips again. The client rings the director. Plans are made
for people to work overtime. Do you need more resources? What if we gave
you two more engineers? Let's do this thing!
7. The deadline is about to slip again. People panic. Engineers start
cutting corners. We'll fix it up later once we've shipped the product.
We'll come back to it later yeah?
8. The project limps over the finish line. Everyone is exhausted, but
elated. Management sends a carton of beer into the development room. Well
done team! Next week, new project!
9. A month later plans are made for a new module to be added. This part of
the code is a bit messy. Let's try to work abound it - we don't have the
budget to do a big refactor here.
10. A year later the software has become a mess. It's sinking under its own
weight. It's hard to implement new functionality without breaking things.
Things are taking too long to implement. The client isn't happy. The
relationship is going south.
It's normal that clients always want to spend less money and have a project
delivered early rather than late. Unfortunately, it's almost a fact of life
that software projects always run late and run over budget. Accept this
fact and you can start thinking clearly about what you do in the face of
pressure. I take the principled stance that code quality is not to be
compromised. Do that, and you might as well give up.
[1]:
http://www.node.mu/2014/02/27/fix-the-broken-windows/
Received on Tue May 26 2015 - 02:36:05 PST