Developing software for corporates- the necessary obfuscation layer

[NickFitz]

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.

And we had this one recently IIRC, but it's also worth a second look: Who Needs Process?

[Platypus]

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]

I send this link to every project manager I work with

Jason Fried: Why work doesn't happen at work | Video on TED.com

[MarillionFan]

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]

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]

And we had this one recently IIRC, but it's also worth a second look: Who Needs Process?

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]

And we had this one recently IIRC, but it's also worth a second look: Who Needs Process?

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...

[d000hg]

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]

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]

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...

Lambs to the slaughter FTW!