Developing software for corporates- the necessary obfuscation layer

[aussielong]

There appears to be a mismatch between how we really develop software and how non-technical management think we develop software.

Breaking it up into tasks up front that get ticked off each day producing a nice graph isn't how we work.

Tasks progress in parallel, many unexpected tasks come up during the day and get done quickly- these eat into my time.

I don't have complete understanding now of how its all going to work - i just have a skeleton plan in my head, which i refine as i get more into the problem. These people dont like to hear "i dont know how that will work yet".

Calling meetings to produce schedules and track progress actually impedes progress because it interrupts us.

Every company i've worked in i've felt like i've had to mislead the management to keep them happy while i tinker away in a completely different world-eventually i produce what they wanted but i've done it in a different way than the project planning would lead you to believe.

Most of the developers around me seem to work like this.

But ... we can't get rid of the layer of management because the ones who pay for our services want to work like that. It probably makes sense for non-development projects. So we have to have this layer of bullsh1t that maps our way of working to their way of working, just to keep everyone happy.

[DieScum]

Yep. I suppose it's a tough problem to solve. There needs to be a way to track progress.

If you put your car in at the garage you want an accurate estimate of how long things will take, what is wrong and what needs to be fixed so you can try and get a handle on whether they are trying to overcharge and are competent and you want it to work at the end. If at some point it looks like it will take longer to fix you need to know so you can plan other transport. Principal-agent problem.

The best way to handle that is to hire a trusted mechanic with good reviews and let them get on with it.

The more complex and high budget things become they less you can just trust someone and the more it needs to be tracked. If you put a fleet of a thousand limousines in to a garage for some upgrade and every day one is out of business costs you a grand you're going to want see planning and progress.

So I think it's necessary sometimes, you can't always just trust, but it's often done so badly and it often gets surreal. I think in the technical side quality and competence are more visible. On the non-technical side a suit and a pleasant manner can disguise incompetence. So a PM or manager can happily waste days of your time on pointless meetings, or valueless charts and look busy and effective while actually doing harm.

Putt's Law put it well "Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand."

[aussielong]

Yep. I suppose it's a tough problem to solve. There needs to be a way to track progress.

If you put your car in at the garage you want an accurate estimate of how long things will take, what is wrong and what needs to be fixed so you can try and get a handle on whether they are trying to overcharge and are competent and you want it to work at the end. If at some point it looks like it will take longer to fix you need to know so you can plan other transport. Principal-agent problem.

The best way to handle that is to hire a trusted mechanic with good reviews and let them get on with it.

Why do you draw a comparison to a car mechanic? Fixing cars is relatively easy.

You should compare yourself to a surgeon?

[NickFitz]

This is one of the problems that Agile tried, in its original form, to address. Of course now its been dressed up as a "methodology" so that chancers can make money out of selling books and training courses, and has thereby turned into just another load of management bulltulip.

But if it's done right, with a good team, it can be an excellent way of actually getting stuff done without having to make crap up just to fool some pointy haired idiot with a Gantt chart.

Incidentally, Microsoft Project is a terrible tool for managing software development projects (though very good if you want to build a bridge or some such). This ought to be obvious from the fact that Microsoft originally developed it to manage their own projects and, since then, have never once delivered a product on schedule

[EternalOptimist]

You take a car mechanic, or a guy digging a field, then stand behind him with a whip and he will work twice as fast. crack the whip and he will work even faster, then whip him a little bit and he work his fastest.
You get a second guy whose job it is to plan the digging, design a digging machine and count the first guys shovel fulls, (a thinking job), and stand behind him with a whip, and nothing will get done.

Some jobs just dont respond to the old school management methods, dev work is one of them.The best dev teams I have seen have come up with their own versions of agile (rad, scrum or whatever you want to call it) and one of the keys is when the project manager realises he is not the boss, but the enabler, the oil between the wheels, the servant.

[SupremeSpod]

Agile does work with adequate buy-in from the developers and customers.

Developers with no social skills, and an over-inflated opinion of their own ability can really **** up your project. Luckily they're going the way of the Dodo.

[MarillionFan]

As the idiot with gannt chart I tend to produce a highly detailed development plan at the beginning of all projects. That is reviewed and agreed with the lead developers and then signed off by the business. This allows me to manage expectations of the client and keep track of the developers. It also allows the identification of issues, time delays and priorisation of scope should we have issues coupled with the ability to line up resources for subsequent phases.

I tick off progress based on key areas both sequential and parallel. The detail is to ensure the developers know what were doing. To be fair though, everything I've had developed in the last few years I've offshored and this 'micro manage' approach ensures I get delivered what we agreed.

[SupremeSpod]

As the idiot with gannt chart I tend to produce a highly detailed development plan at the beginning of all projects. That is reviewed and agreed with the lead developers and then signed off by the business. This allows me to manage expectations of the client and keep track of the developers. It also allows the identification of issues, time delays and priorisation of scope should we have issues coupled with the ability to line up resources for subsequent phases.

I tick off progress based on key areas both sequential and parallel. The detail is to ensure the developers know what were doing. To be fair though, everything I've had developed in the last few years I've offshored and this 'micro manage' approach ensures I get delivered what we agreed.

And when MF's project goes titsup, I'll dig it out of the mire - for a price.

[MarillionFan]

And when MF's project goes titsup, I'll dig it out of the mire - for a price.

Has Suity got your pager number yet?

[SupremeSpod]

Has Suity got your pager number yet?

It's called job creation, mate.

"Suity the Project Manager - Can he fix it? No it's f*cked!"