How Plans Kill Productivity(assistwindow.com)
assistwindow.com
How Plans Kill Productivity
http://assistwindow.com/bwm/posts/how-plans-kill-productivity/
25 comments
That's a very sad view on the employer-employee relationship. I assume that's why inteligent people are hired in general - pretty much the opposite of what you wrote. Unless you're an assembly line worker and your position is just not important enough to be replaced by a machine (yet), I would hope that any improvements you can come up with are going to be respected. Not necessarily accepted and implemented but at least considered.
I'd really hate to ever be in a position where an overall improvement is treated as a bad thing because of politics.
I'd really hate to ever be in a position where an overall improvement is treated as a bad thing because of politics.
> Unless you're an assembly line worker
You've never worked on an assembly line or talked to anyone who has, have you? Assembly line workers come up with ideas for improved efficiencies on the line all the time. They aren't generally welcome to share them, however; it's usually better for their job security to keep them to themsleves in fact. In that respect, much like many office jobs.
You've never worked on an assembly line or talked to anyone who has, have you? Assembly line workers come up with ideas for improved efficiencies on the line all the time. They aren't generally welcome to share them, however; it's usually better for their job security to keep them to themsleves in fact. In that respect, much like many office jobs.
My experience in software is similar. While companies go out of their way to hire smart people who regularly come up with improvements to how things are done, their efforts are easily thwarted by the marching morons of the status quo (which is obviously working so what's the problem?). Those who luck out and break out from the herd to implement those improvements end up getting promoted.
But in the employer's defense, once these guys are in the driver's seat, it can frequently be hard to distinguish the signal from the smart guys from the rantings of particularly vocal morons.
I think the take home lesson is to be very careful choosing your co-workers and manager.
As for the subject of this thread, there are no magic bullets, right? Sometimes a plan is awesome when the target is clear. Other times it only gets in the way when one is doing a significant amount of research in parallel with the development. And everything in between...
But in the employer's defense, once these guys are in the driver's seat, it can frequently be hard to distinguish the signal from the smart guys from the rantings of particularly vocal morons.
I think the take home lesson is to be very careful choosing your co-workers and manager.
As for the subject of this thread, there are no magic bullets, right? Sometimes a plan is awesome when the target is clear. Other times it only gets in the way when one is doing a significant amount of research in parallel with the development. And everything in between...
Have you not worked in an office environment at a medium to large sized company yet? As cynical as the original comment comes across it neatly encapsulates the realities of working in that kind of environment.
Even if your you manager supports the idea, if it crosses over into other managers areas they may resent the change. And if you have a stack rank review system those other managers can kill your review. I've seen it happen.
I do work in a (very) large company. I also managed to be fairly successful in ignoring the politics and just doing the job, raising issues with processes and problems in my and other teams when I saw them. If I'm ever punished for doing that, I'll start sending out my resume to other companies most likely.
That's perfectly possible if you have strong enough position and you are ok with some people hating you silently.
That's my perception and experience, too.
True, Startups are much more Agile and they some how just don't feel the need of documenting things too much...
Plans that people rigidly adher to even though the information they were based on is completely outdated are pretty bad.
But know what's even worse? Having no plan at all, or just a vague mission statement. Because then you have no way to answer the question "what do I do next and how do I know it's finished?", and you end up yak shaving, turd polishing, working at cross purposes and just plain killing time, often way past the point where the project cannot achieve its goals any more and just lacks someone with the courage to kill it.
To be useful, a plan has to be updated regularly.
But know what's even worse? Having no plan at all, or just a vague mission statement. Because then you have no way to answer the question "what do I do next and how do I know it's finished?", and you end up yak shaving, turd polishing, working at cross purposes and just plain killing time, often way past the point where the project cannot achieve its goals any more and just lacks someone with the courage to kill it.
To be useful, a plan has to be updated regularly.
It feels easy to blame planning. If I take your interpretation, plans are checklist tasks or milestones for management to measure developer progress. At worst a plan can be something you create for someone else to flog you with it. These sort of plans are also by their nature almost always inaccurate to some degree.
To my mind a good plan is one where it can provide context for an entire team about where and what (to some level of accuracy) needs to be done. Part of planning is to reduce the principle-agent type problems that come with software. Individual developers are responsible for their own plan and it isn't too constrained so at their own liberty people can swap or modify what they need to do without centralized agreement.
Planning isn't easy, and I agree that sometimes the best plan for some types of work is to be very short term and iterative.
To my mind a good plan is one where it can provide context for an entire team about where and what (to some level of accuracy) needs to be done. Part of planning is to reduce the principle-agent type problems that come with software. Individual developers are responsible for their own plan and it isn't too constrained so at their own liberty people can swap or modify what they need to do without centralized agreement.
Planning isn't easy, and I agree that sometimes the best plan for some types of work is to be very short term and iterative.
Straw man argument.
A more accurate title would be "How Bad Project Management Kills Productivity". It's like the author has never heard of Rolling Wave planning [1]
[1] http://en.wikipedia.org/wiki/Rolling_Wave_planning
A more accurate title would be "How Bad Project Management Kills Productivity". It's like the author has never heard of Rolling Wave planning [1]
[1] http://en.wikipedia.org/wiki/Rolling_Wave_planning
Well, Your title suggestion inspires me to write another article around management and productivity but I need some more research for it :)
:-)
It grinds my gears how we get articles along the lines of "I worked somewhere with pathological project management. Therefore all project management is stupid. YAY DEVELOPERS!!"
It grinds my gears how we get articles along the lines of "I worked somewhere with pathological project management. Therefore all project management is stupid. YAY DEVELOPERS!!"
Great article. Funny thing that I was planning with my colleagues a project right before I read it and we realised that planning is not going to help a lot.
I mean it's cool to have some rough estimate but you can never be accurate, especially when a project involves doing things for the first time (ie. innovating)
I mean it's cool to have some rough estimate but you can never be accurate, especially when a project involves doing things for the first time (ie. innovating)
Thanks Nikolas! Glad you liked it!
As a developer recently turned project manager I've come to learn a lot about planning and documentation. I understand the reluctance to plan, and to create project documents at the beginning of a project.. but there are good reasons.
One of the key was to create an environment where developers are free from distraction and able to efficiently develop is to have someone plan, and to communicate.
Here's my (somewhat brutal) response to your article: http://beardedinventor.com/blog/2013/01/23/plans-dont-kill-p...
One of the key was to create an environment where developers are free from distraction and able to efficiently develop is to have someone plan, and to communicate.
Here's my (somewhat brutal) response to your article: http://beardedinventor.com/blog/2013/01/23/plans-dont-kill-p...
I am having a serious deja vu reading this. I am pretty sure I have read a post exactly like this one here on HN that suggested plans destroy developer interest/creativity and they end up just following the plan instead of suggesting something that they think would be better. It was long time ago.
I ended up blogging in response - http://rtigger.com/blog/2013/01/23/short-term-planning/
TL;DR - I agree, and highlight how the short-term planning process baked into most agile approaches addresses this problem.
TL;DR - I agree, and highlight how the short-term planning process baked into most agile approaches addresses this problem.
Cool!
This is talking about "plans" in the sense of a grand plan not like, "I plan to get x done today" which I find quite helpful in being productive.
Indeed, even team planning, goal settings, ... are useful to avoid wasting time on low value stuff, or getting stuck when others can help.
Problem of project plan generally is the divide and conquer approach. Work is divided in various independent streams, but plan very often fail to consider that the final product need to be whole and underestimate the merging side of stuff.
Getting the balance right is always the problem. Applies not only to planning, but to testing, designing, documenting, certifying, optimizing, supporting, ...
Problem of project plan generally is the divide and conquer approach. Work is divided in various independent streams, but plan very often fail to consider that the final product need to be whole and underestimate the merging side of stuff.
Getting the balance right is always the problem. Applies not only to planning, but to testing, designing, documenting, certifying, optimizing, supporting, ...
Thanks pmorici! Glad you liked it!
If I don't have "You are to save your employer and your management from consequences of their stupidity." written in job description then I don't see why should I provide them with my insight unasked. Especially since no good deed goes unpunished.
For example while working at corporation I may have an idea of how to do some things simpler but I can't take for granted that making things simpler is beneficial to my supervisor or the team he supervises. Voicing my idea could put my supervisor in awkward situation.
I suppose start-ups are more straightforward.