The words "building a software solution" can apply to any business. From
a lady displaying home-made dresses on a webpage to a company hosting 50
seperate systems, using 2 database platforms, with CRM's, ERPs (you get
the idea).
How we approach all the businesses in between will vary considerably.
Some businesses do not require full-blown SSADM type development. Some
require parts, other consultants walk into large companies only to find
a mess. Data routing everywhere, no consistency, updates happening in
weird places. Sometimes it can take a month just to understand what's
going on.. with dodgy or outdated software documentation, requirements
hacked etc.
Consultants walk into a business, be it the lady with her dresses or
(eg) Rogers Group with different attitudes in mind. Yes you'd expect the
major companies to be smart too.
But let's define "smart" for a moment.
How "smart" is a company who appoints their own relatives at the top of
the chain? Or their newly qualified nephews to be "Head of IT" in some
place? This idiot will call the shots here don't forget. So now what do
you do? Spend a week on the whiteboard explaining WHY something is so
good for him?
And what if the big consultancies just drive in with a Porsche-clad
consultant, show them some generic software (SAP?), throw a whole load
of reports, graphs at him, wines and dines then Uncle suddenly disburses
Rs 10 Million for a system which needs Rs 5 M customisation and Rs 5M
support a year (probably through bad customisations?.. not respecting
the proper business processes? adding extra work all round and
introducing ambiguity and errors?).
These are the idiots I talk about.
So... back to topic. When you are dealing with a SMART business.. that's
when, I feel at least, we can talk SMART back to them. Yes I have time
to educate them, but I have no time to educate them on the merits of
appointing smart decision makers in their businesses to meet smart
consultants.
Just my opinion
Dhiruj
On 26/05/2015 06:35, Vy-Shane Sin Fat wrote:
> On Tue, May 26, 2015 at 1:16 AM, Dhiruj Rambaran <dhiruj_at_shoponline.mu
> <mailto: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 <mailto: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 - 04:05:38 PST