PDA

View Full Version : Developing software for corporates- the necessary obfuscation layer



aussielong
4th May 2012, 00:50
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
4th May 2012, 02:38
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
4th May 2012, 03:19
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? :wink

NickFitz
4th May 2012, 06:13
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 bullshit.

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
4th May 2012, 06:38
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.



:rolleyes:

SupremeSpod
4th May 2012, 06:50
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
4th May 2012, 07:02
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
4th May 2012, 07:05
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
4th May 2012, 07:07
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?:wink

SupremeSpod
4th May 2012, 07:11
Has Suity got your pager number yet?:wink

It's called job creation, mate.

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

cojak
4th May 2012, 07:15
Adaptive Case Management - it's the future...

SupremeSpod
4th May 2012, 07:17
Adaptive Case Management - it's the future...

Put the kettle on while you're up and about sweetheart!

fullyautomatix
4th May 2012, 07:23
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.


Agile led by a solution architect and with full support of developers will work really well. But some scrummaster who isnt technical but from project management background can really **** it up.

mudskipper
4th May 2012, 07:23
I use FUDGE and FUMBLE

F****'s Unique Design Generation Engine
and
F****'s Universal Methodology for Big and Little Endeavours.

(where F**** is k2p2's other handle)

Works for me.

£5k and I'll share my secrets.

SupremeSpod
4th May 2012, 07:24
Agile led by a solution architect and with full support of developers will work really well. But some scrummaster who isnt technical but from project management background can really **** it up.

Yeah, that as well.

Just give Cojak a shout and find out where my brew is!

SupremeSpod
4th May 2012, 07:25
I use FUDGE and FUMBLE

F****'s Unique Design Generation Engine
and
F****'s Universal Methodology for Big and Little Endeavours.

(where F**** is k2p2's other handle)

Works for me.

£5k and I'll share my secrets.

We've already seen your tits.

fullyautomatix
4th May 2012, 07:29
Yeah, that as well.

Just give Cojak a shout and find out where my brew is!


Based on the Gnatt chart she has produced your brew would be ready in 4 hours 20 minutes. She has factored in risk of electricity being switched off, water being switched off etc and added in 20% for contingency and build time.

cojak
4th May 2012, 07:30
(and spat in it...)

SupremeSpod
4th May 2012, 07:32
(and spat in it...)

You should see what I left in your shoes :wink

MarillionFan
4th May 2012, 07:32
(and spat in it...)

He's used to that. He was in the army after all.:rolleyes:

NickFitz
4th May 2012, 07:54
A classic one from Eric Lippert (Whom God Preserve) about what it takes to add a feature at Microsoft: How many Microsoft employees does it take to change a lightbulb? - Fabulous Adventures In Coding - Site Home - MSDN Blogs (http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx).

And we had this one recently IIRC, but it's also worth a second look: Who Needs Process? (http://teddziuba.com/2011/12/process.html)

Platypus
4th May 2012, 08:08
when the project manager realises he is not the boss, but the enabler, the oil between the wheels, the servant

Exactly correct. Well said.

bobspud
4th May 2012, 08:23
I send this link to every project manager I work with

Jason Fried: Why work doesn't happen at work | Video on TED.com (http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work.html)

MarillionFan
4th May 2012, 08:25
Exactly correct. Well said.

Actually he's the designated driver who has to spend a lot of time stopping the drunken passengers from grabbing the wheel and pulling the car off the road.

darmstadt
4th May 2012, 08:32
I use FUDGE and FUMBLE

F****'s Unique Design Generation Engine
and
F****'s Universal Methodology for Big and Little Endeavours.

(where F**** is k2p2's other handle)

Works for me.

£5k and I'll share my secrets.

Must be the updated version of my methodology, BODGIT and LEGGIT (invoice paid first though.)

Sysman
4th May 2012, 08:58
And we had this one recently IIRC, but it's also worth a second look: Who Needs Process? (http://teddziuba.com/2011/12/process.html)

I like this bit:


Software development processes exist to manage the bell curve of ability in developers. It's simple mathematics. The more people you collect on a team, the more likely it is that the team's average skill is the average skill of software developers as a whole. This is the Strong Law of Large Numbers, and it is non-negotiable. There's not a meeting you can hold to make it go away. Most organizations simply accept their fate, and design policies and procedures to keep the back half of the bell curve from causing damage.

cojak
4th May 2012, 09:06
And we had this one recently IIRC, but it's also worth a second look: Who Needs Process? (http://teddziuba.com/2011/12/process.html)

It's taken me a while but I'm with you Nick. And for a BA who used to specialise in process analysis, that's some going.

With any luck I'll be able to corrupt the system from the inside until they ask for my badge back... :glasses

d000hg
4th May 2012, 09:06
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 think that's the best way to work. It is better to work on discrete tasks and only switch task on completion. Obviously a large feature can be broken into small tasks and then you try to finish your current sub-task before moving to fix a bug elsewhere in the project.

MarillionFan
4th May 2012, 09:14
I don't think that's the best way to work. It is better to work on discrete tasks and only switch task on completion. Obviously a large feature can be broken into small tasks and then you try to finish your current sub-task before moving to fix a bug elsewhere in the project.

Most developers stuggle with managing to get to the office on time(that's why their mums put them on the bus) how on earth do you expect them to manage their time on a project! The PM is their surrogate mum.

NickFitz
4th May 2012, 09:15
It's taken me a while but I'm with you Nick. And for a BA who used to specialise in process analysis, that's some going.

With any luck I'll be able to corrupt the system from the inside until they ask for my badge back... :glasses

Lambs to the slaughter FTW! :yay:

aussielong
4th May 2012, 14:24
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.

Do you work on small projects that have very clear requirements?

How can you possibly plan everything up front and offshore dev otherwise?

Or are your devs working from a different plan to you?

minestrone
4th May 2012, 15:02
I have on my desk a 96 page 'agile playbook' which describes client co's lightweight process which we all have to follow.

I honestly have no energy now to attempt to critique this tulipe, I just follow along with the madness.

MarillionFan
4th May 2012, 15:12
Do you work on small projects that have very clear requirements?

How can you possibly plan everything up front and offshore dev otherwise?

Or are your devs working from a different plan to you?

Business Intelligence is a little more predictable.

Lockhouse
4th May 2012, 15:16
My entire IT career has been based on expectation mangement.

VectraMan
4th May 2012, 16:03
I like to ignore the process and get on with the work. Inevitably this causes some friction, but you have some time. PMs by definition don't work very hard and don't understand what the people they take credit for are actually doing, so you have a few weeks before anybody will realise you're not working in the way you're meant to be. And then it'll be a murmur, a few emails, a few reminders. Keep ignoring the process and the murmurs will get louder, with the inevitable conclusion that the more senior management get involved and you get fired.

So the challenge is to finish the work before that point. Then the senior management are delighted with you and when the PM comes along telling him you should be fired for not doing work, he's rightly exposed as the entirely useless waste of money and space that he is.

minestrone
4th May 2012, 16:56
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.



The best PM I ever worked for got the team together at some point in the morning, no fixed time in the calendar to make him look as if he was busy, just "quick 2 min catch up".

He would ask you what you were working on and then say stuff like...

"is there anything I can do to keep you productive?" "any issues with any other teams?" "I can chase that down for you" "I will deal with that for you"

He basically viewed himself as a path clearer for work to be done. Unique and refreshing.

doodab
5th May 2012, 05:04
"I can chase that down for you" "I will deal with that for you"

He basically viewed himself as a path clearer for work to be done. Unique and refreshing.

Whereas the bad ones like to delegate every random piece of shit they can to you.

suityou01
5th May 2012, 08:48
I have some strong opinions on this one. Every company is different. Processes differ, but in all cases there is a process. It is undeniable. I fully understand creative types don't like doctrine and I have worked in a lot of shite places where managers pomp about arranging pointless meetings and get all shouty when the don't like what they hear. I've also seen the other side of the coin where hands off management is killing a project also, I believe there was a thread on here recently from NWPTC about how soul destroying that is.

Without process there is chaos. The level of process a team needs for optimum performance is subjective, and is generally based on the quality, or indeed competency of said team. Extreme examples include local government, who generally employ low grade staff and layer on the red tape. Or the trade union mentality. Or off-shore teams needing micromanaging. Thick with process, inefficient.

For those who understand these things, it's like we need some power factor correction between the stuff doers and the management. With unity power factor being the holy grail. For those that don't understand PFC, it's essentially a way of getting the most efficient work out of an electrical device. If you have a factory with lots of electrical motors then due to the nature of the motors, they actually impede the flow of electricity because they have lots of windings, and this causes a lag. This lag causes overheating and this heat that is lost is energy that could have been spent doing work. [Very oversimplified explanation of PFC].

Or a bit like when I was in swimming classes, you get your stroke wrong and you make lots of foam but don't get much movement. Get it right and you are putting in lots of laps.

So for me getting the process right is about how much process as well as what the process is.

What I didn't want to see in this thread was the petulant rantings of the self obsessed "creative types" carrying on as if those who hired them have no right to formulate how they keep tabs on where there money goes.

fullyautomatix
5th May 2012, 09:09
I have some strong opinions on this one. Every company is different. Processes differ, but in all cases there is a process. It is undeniable. I fully understand creative types don't like doctrine and I have worked in a lot of tulipe places where managers pomp about arranging pointless meetings and get all shouty when the don't like what they hear. I've also seen the other side of the coin where hands off management is killing a project also, I believe there was a thread on here recently from NWPTC about how soul destroying that is.

Without process there is chaos. The level of process a team needs for optimum performance is subjective, and is generally based on the quality, or indeed competency of said team. Extreme examples include local government, who generally employ low grade staff and layer on the red tape. Or the trade union mentality. Or off-shore teams needing micromanaging. Thick with process, inefficient.

For those who understand these things, it's like we need some power factor correction between the stuff doers and the management. With unity power factor being the holy grail. For those that don't understand PFC, it's essentially a way of getting the most efficient work out of an electrical device. If you have a factory with lots of electrical motors then due to the nature of the motors, they actually impede the flow of electricity because they have lots of windings, and this causes a lag. This lag causes overheating and this heat that is lost is energy that could have been spent doing work. [Very oversimplified explanation of PFC].

Or a bit like when I was in swimming classes, you get your stroke wrong and you make lots of foam but don't get much movement. Get it right and you are putting in lots of laps.

So for me getting the process right is about how much process as well as what the process is.

What I didn't want to see in this thread was the petulant rantings of the self obsessed "creative types" carrying on as if those who hired them have no right to formulate how they keep tabs on where there money goes.


What Suity said.

(although I have no clue what all that bollox he has written means)

minestrone
5th May 2012, 09:23
I have some strong opinions on this one. Every company is different. Processes differ, but in all cases there is a process. It is undeniable. I fully understand creative types don't like doctrine and I have worked in a lot of tulipe places where managers pomp about arranging pointless meetings and get all shouty when the don't like what they hear. I've also seen the other side of the coin where hands off management is killing a project also, I believe there was a thread on here recently from NWPTC about how soul destroying that is.

Without process there is chaos. The level of process a team needs for optimum performance is subjective, and is generally based on the quality, or indeed competency of said team. Extreme examples include local government, who generally employ low grade staff and layer on the red tape. Or the trade union mentality. Or off-shore teams needing micromanaging. Thick with process, inefficient.

For those who understand these things, it's like we need some power factor correction between the stuff doers and the management. With unity power factor being the holy grail. For those that don't understand PFC, it's essentially a way of getting the most efficient work out of an electrical device. If you have a factory with lots of electrical motors then due to the nature of the motors, they actually impede the flow of electricity because they have lots of windings, and this causes a lag. This lag causes overheating and this heat that is lost is energy that could have been spent doing work. [Very oversimplified explanation of PFC].

Or a bit like when I was in swimming classes, you get your stroke wrong and you make lots of foam but don't get much movement. Get it right and you are putting in lots of laps.

So for me getting the process right is about how much process as well as what the process is.

What I didn't want to see in this thread was the petulant rantings of the self obsessed "creative types" carrying on as if those who hired them have no right to formulate how they keep tabs on where there money goes.

It is like a dilbert cartoon with no images and more words

darrenb
5th May 2012, 17:30
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.


Software development is a completely different ballgame to auto repair. A big part of the problem is that people try to squeeze technological innovation into an old industrial economic model through bogus comparisons with blue collar work (and this is surely how offshoring started).



The more complex and high budget things become they less you can just trust someone and the more it needs to be tracked.


I'd like to modify that statement in a couple of ways.

Firstly, the more complex and innovative things become the less you can track it. Of course, you can put in lots of pretend tracking in there, but all it's going to do is interfere with the actual process, and I think the OP made that point very well. I would add that a key goal of tracking is to find and use generic metrics, but what is actually important within an innovative process is completely dependent on context, so this is just the Don Quixote of Managerialism flailing at windmills again.

Secondly, the more complex things become, the more you have to rely on trust. That can be tough to establish -- impossible, even, if you yourself are not a trustworthy person. But ultimately the only way to get something as complex as software done is to spread around good will and hope it sticks. If it turns out that you can't trust your people, your best course is simply to admit failure at the start and save the shareholders/investors/taxpayers from wasting millions. Now I know no exec would ever do that, but just imagine how helpful it would be if they did and cleared the way for projects that actually have a snowball's chance in hell of succeeding.



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.


If a heart surgeon is performing on you, you're going to want to see progress too. But you can't. Why not? Sorry, you're simply not qualified, and you wouldn't understand what is going on even if you could observe and weren't blissfully unconscious (of all the little mistakes and corrections going on).

So at some point you just have to trust the professionals. If you've managed to successfully de-professionalize IT, then once again, sorry, you're out of luck.

minestrone
5th May 2012, 21:42
Software development is a completely different ballgame to auto repair. A big part of the problem is that people try to squeeze technological innovation into an old industrial economic model through bogus comparisons with blue collar work (and this is surely how offshoring started).



I'd like to modify that statement in a couple of ways.

Firstly, the more complex and innovative things become the less you can track it. Of course, you can put in lots of pretend tracking in there, but all it's going to do is interfere with the actual process, and I think the OP made that point very well. I would add that a key goal of tracking is to find and use generic metrics, but what is actually important within an innovative process is completely dependent on context, so this is just the Don Quixote of Managerialism flailing at windmills again.

Secondly, the more complex things become, the more you have to rely on trust. That can be tough to establish -- impossible, even, if you yourself are not a trustworthy person. But ultimately the only way to get something as complex as software done is to spread around good will and hope it sticks. If it turns out that you can't trust your people, your best course is simply to admit failure at the start and save the shareholders/investors/taxpayers from wasting millions. Now I know no exec would ever do that, but just imagine how helpful it would be if they did and cleared the way for projects that actually have a snowball's chance in hell of succeeding.



If a heart surgeon is performing on you, you're going to want to see progress too. But you can't. Why not? Sorry, you're simply not qualified, and you wouldn't understand what is going on even if you could observe and weren't blissfully unconscious (of all the little mistakes and corrections going on).

So at some point you just have to trust the professionals. If you've managed to successfully de-professionalize IT, then once again, sorry, you're out of luck.

I have to say, that is an outstanding post.

Just a shame it is a complete pile of absolute tripe.

aussielong
7th May 2012, 03:21
I have some strong opinions on this one. Every company is different. Processes differ, but in all cases there is a process. It is undeniable. I fully understand creative types don't like doctrine and I have worked in a lot of tulipe places where managers pomp about arranging pointless meetings and get all shouty when the don't like what they hear. I've also seen the other side of the coin where hands off management is killing a project also, I believe there was a thread on here recently from NWPTC about how soul destroying that is.

Without process there is chaos. The level of process a team needs for optimum performance is subjective, and is generally based on the quality, or indeed competency of said team. Extreme examples include local government, who generally employ low grade staff and layer on the red tape. Or the trade union mentality. Or off-shore teams needing micromanaging. Thick with process, inefficient.

For those who understand these things, it's like we need some power factor correction between the stuff doers and the management. With unity power factor being the holy grail. For those that don't understand PFC, it's essentially a way of getting the most efficient work out of an electrical device. If you have a factory with lots of electrical motors then due to the nature of the motors, they actually impede the flow of electricity because they have lots of windings, and this causes a lag. This lag causes overheating and this heat that is lost is energy that could have been spent doing work. [Very oversimplified explanation of PFC].

Or a bit like when I was in swimming classes, you get your stroke wrong and you make lots of foam but don't get much movement. Get it right and you are putting in lots of laps.

So for me getting the process right is about how much process as well as what the process is.

What I didn't want to see in this thread was the petulant rantings of the self obsessed "creative types" carrying on as if those who hired them have no right to formulate how they keep tabs on where there money goes.

Don't disagree with you about needing some process.

What I'm saying is the real process of developing does not match the management requirements of a process.

I have multiple aspects of the program on the go at once, I build end to end and keep iterating until I'm done, at certain points I stand back and check I've not gone mad-refactor

I'm going over requirements all the time to make sure nothng drops down the cracks

The "design" is complete when I'm finished building

At the end, I apply a few design patterns where necessary... This is like tidying up my hand writing (in the real world)

Always thinking about testing and test ability

This is my process and it works for me

cojak
7th May 2012, 06:55
I used to be like Suity. I'm not anymore.

I am a BA, I no longer believe in process. I say Adaptive Case Management is the future. Many otherwise competent professionals (a bit of a stretch i know but work with me on this) say they hate process. There's something in there if you care to look.

There's nothing wrong with process for routine, repetitive tasks.

But if you ask people doing emergent, unpredictable, non-repeatable work if they follow process, 80% of the time they'll say 'no'. They are knowledge workers and current process analysis and management doesn't really work for them. This is where ACM comes into play.

I'm not going into ACM here (because it's a holiday and I can't be arsed), but essentially it ensures that those closest to the 'process' can adapt it.

doodab
7th May 2012, 07:18
The key to successful collaboration is to understand that the structure a PM will try to impose is driven by their needs. The more enlightened ones will show an interest in helping you do your job as well but it's by no means a given.

It used to be the case that I thought I didn't have a process, but the more I thought about it the more I realised I did, it just wasn't the process that the MS project jockeys had written down. Now I'm older and wiser I generally try and work with the PM and either restructure the plan to reflect reality a little better or at the very least de risk it by bringing obviously high risk unknowns forwards (for some reason human nature is to tack these on the end after all of the stuff we already know how to do) and in the worst case just bullshit them to ensure that there are as many days as I think I need while accommodating various uncertainties.

This usually goes along the lines of putting a couple of client demos in the development phase which pleases them no end as I usually commit to demoing certain functionality at those points and it gives them a clear opportunity to track progress. That commitment will buy you some trust and flexibility elsewhere.

BlasterBates
7th May 2012, 08:26
If you don't break your project down into small doable tasks you are going to end up with an amorphous large piece of software that doesn't work.

For example get the bit working that reads from the database, then get the bit working that aggregates the data. Next get the bit working that sends the data to the client etc etc.

You ought to be able to plan that.

1) read from the database - 2 weeks
2) aggregate data - 1 week

Also a good idea to do an overall design and identify the components you're going to develop, so you can map the components to your implementation plan. I always do a detailed design before I start any siginificant development, yup it might change somewhat but it should be pretty firm. Then you need milestones.

I mean if you 're going to read from the database you know you need a class that connects to the database and some Data reader don't you. Then for aggregation you know you need something that sits on top and puts stuff in vectors adding everything up etc etc.

One problem is that requirements aren't understood first, sometimes too vague, maybe that's the problem.

If there are questions on the requirements, good idea to write an acceptance test specification, that is a great way of clarifying everything. Describe all the test cases and then there is no question that what you've done is as they "want it".

d000hg
7th May 2012, 09:10
PMs by definition don't work very hard and don't understand what the people they take credit for are actually doingNo, not by definition. Bad PMs may be like that, but bad developers are no better.


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.Hit the proverbial nail there EO. Of course this requires the PM to trust his developers are good at their jobs, if he has resources foisted upon him this all goes wrong.

BlasterBates
7th May 2012, 10:31
I used to be like Suity. I'm not anymore.

I am a BA, I no longer believe in process. I say Adaptive Case Management is the future. Many otherwise competent professionals (a bit of a stretch i know but work with me on this) say they hate process. There's something in there if you care to look.

There's nothing wrong with process for routine, repetitive tasks.

But if you ask people doing emergent, unpredictable, non-repeatable work if they follow process, 80% of the time they'll say 'no'. They are knowledge workers and current process analysis and management doesn't really work for them. This is where ACM comes into play.

I'm not going into ACM here (because it's a holiday and I can't be arsed), but essentially it ensures that those closest to the 'process' can adapt it.

aha this reminds me of the notion of "contingency", if I maybe academically pompous for a minute or two.

In Organisational theory there are different ways of management ranging from a "power based" culture to a bureacratic. If it is unstructured then you need a manager who is akin to God, basically behaving in a slightly bullying way to get things done but no procedures, otherwise you have unstructured chaos, this is what you need in a small start up company...f*** the procedures roll your sleeves and get it done, but with someone in charge who knows where he's going. Then there's move towards large orgs like banks where you need procedures design and all those boring things that get on developer's nerves but if you don't do it you could end up like Barings or Lehmans .....on the rocks.

cojak
7th May 2012, 10:39
Well the 'why' and the 'what' are important (goals, legislative rules etc).

But the 'how'... leave it to the specialists to work that out. They're usually better at it than non-specialists.