Is Project Management Killing Good Products, Teams and Software? (techbeacon.com) 176
New submitter mikeatTB writes: "For software development, no significant developer activity is predictable or repetitive; if it were, the developers would have automated it already," writes Steven A. Lowe, Principal Consultant Developer at ThoughtWorks, via TechBeacon. "In addition, learning is essentially a nonlinear process; it involves trying things that don't work in order to discover what does work. You might see linear progress for a while, but you don't know what you don't know, so there will be apparent setbacks. It is from these setbacks that one learns the truth about the system -- what is really needed to make it work, to make it usable, and to make a difference for the users and the business. In other words, the dirty little secret of software development is that projects don't really exist. And they're killing our products, teams, and software." Lowe continues: "Projects, with respect to software development, are imaginary boxes drawn around scope and time in an attempt to 'manage' things. This tendency is understandable, given the long fascination with so-called scientific management (a.k.a. Taylorism, a.k.a. Theory X), but these imaginary boxes do not reduce underlying complexity. On the contrary, they add unnecessary complexity and friction and invite a counterproductive temptation to focus on the box instead of the problem or product. This misplaced emphasis leads to some harmful delusions: Conformance to schedule is the same thing as success; Estimation accuracy is possible and desirable enough to measure and optimize for; The plan is perfect and guarantees success; The cost of forming and dissolving teams is zero; The cost of functional silo hand-offs is zero; The bigger and more comprehensive the plan, the better; Predictability and efficiency are paramount."
Eisenhower (Score:5, Insightful)
To quote Dwight D. Eisenhower, "In preparing for battle, I have always found that plans are useless but planning is indispensable."
If you go into a major project without some sort of project management, it's not going to end well. However, the management of the project needs to be flexible enough to adapt to the changing environment. Decent project management will see when things are under resourced, and help to fill in those gaps (if possible), and should keep the project going in the right direction.
Re:Eisenhower (Score:5, Insightful)
Decent project management will see when things are under resourced, and help to fill in those gaps (if possible), and should keep the project going in the right direction.
That's (probably) more mythical man month PM bullshit right there.
Generally in a software project "under-resourced" means the milestones aren't being reached, which either means you have bad milestones, bad requirements, or bad coders.
Adding another 5 coders to part of the project doesn't make it go faster if the first one has written a pile of garbage and it needs to be unpicked or more likely the new coders are rubbish and no one wanted them on their project, so they're available to "help".
Most PMs I've met have been great people with great PM skills, and no clue if what a coder is telling them is accurate. I'm sure there's some counter-example with great code assessment skills, but that doesn't make them representative of the class.
Re:Eisenhower (Score:5, Insightful)
Generally in a software project "under-resourced" means the milestones aren't being reached, which either means you have bad milestones, bad requirements, or bad coders.
I guess I didn't make myself sufficiently clear, and you hit the nail on the head. By resources I was meaning not just people, but equipment, tools, requirements, knowledge, plans, or is it just bad milestones to begin with. Adding more people to a failing project is a recipe to make it fail faster, the solution is to figure out what's going on early so the problems can be resolved.
Re:Eisenhower (Score:5, Insightful)
Ah, fair enough. I've seen at least one manager kill a project at birth since it was not possible to do, but that's pretty rare.
Also, I'd forgotten the absolute worst PM trend; project is going too slowly, we need a daily meeting that we'll pretend is 15 minutes, but is actually an hour and probably subtracts 2 from the day with prep and recovery.
Re: (Score:2)
Re: (Score:3)
No, the absolute worst is the all hands status meeting. I had one PM do that every Friday. Everyone who worked for him had to attend (we were a small company, so it was about 20+ people from every department). (!!! ALERT !!!! Useless meeting sign #1 - More people are attending than necessar
Re: (Score:3)
These are all possible. It's also possible that requirements have been changed (because it has come to light that the original ones are bad). In fact the larger the scope of the project is, the more likely it is that the original plan is not comprehensive and things will come up during development that require the tweaking of the requiremen
Re: (Score:3)
Many of the projects I work on would do great with extra people. Work where we have thousands of hours needed to develop sufficient testing for certification of the software. A vast majority of these tests are independent enough that you could throw a separate expert at each test and get them done in no time at all.
The problem that management fails to grasp is a smart person who has worked on similar projects is not an expert at this particular project. When we throw a bunch of new people at it, the bott
Re: (Score:3)
That's silly. Depending on the size of the project and how good the team is at developing a work breakdown (decomposing big tasks into smaller, but still well-defined, ones), more than 50% and probably more than 75% of any project will look familiar. You may be developing a new web service, but if you've done NoSQL
Re: (Score:2)
Yes, TFS is all straw man. *Consistently* wrong (Score:5, Insightful)
Indeed, while poorly done planning is useless, or worse, PROPER planning can be VERY useful.
Here's a very important fact - programmers consistently over-estimate how much they can get done in a week or a month. Consistently, that's the key word. We're wrong about how long things will take, but we're wrong in a fairly predictable way. If tasks are well defined, programmers are pretty good at estimating the RELATIVE size of job - task A will likely take about twice as long as task B. Here's what the planned productivity vs actual completed tasks might look like for a typical Agile team, with the amount done measured in "story points":
Sprint #. Plan Actual completed
Sprint 1. 124 98
Sprint 2. 105 96
Sprint 3. 131 102
Sprint 4. 116 97
The team fell short of their plan every time. And they pretty consistently get about 98 points. If management believes the 131 number, there will be problems. It works pretty well if management looks at historical fact and says "this team completes about 98 points per sprint. Let's do the project plan based on 85 points total for the team."
Let's address the "delusions" (straw men) that the author sets up:
> The plan is perfect and guarantees success;
Perfection is not required for something to be valuable. The author's proposal is even LESS perfect. While a plan can't guarantee success, it does at least define success, so you know when you're done, and what you're aiming for. Failing to plan, on the other hand, almost guarantees perpetual scope-creep, where a project can never be a success because it never ends.
> The cost of forming and dissolving teams is zero;
Very often the cost of forming a team is WORTH IT
> The cost of functional silo hand-offs is zero;
Again, not zero, but worth it
> The bigger and more comprehensive the plan, the better;
If you don't have a big-picture plan of what your company or organization is trying to do, what are the odds that you'll accidentally accomplish it?
More specifically, what often happens without a big-picture plan is that functional level teams such as programmers do cool stuff that gets abandoned shortly afterward. They may spend a month integrating the systems of a division that gets sold off two months later. They may do cool stuff for managing desktop applications, while another team is busily moving everything to the cloud.
> Predictability and efficiency are paramount.
Your idea for what you want your team to do sounds good. My different idea sounds good. So does Kevin's idea. Unless we find a way to predict how long these projects will take, WE DON'T KNOW IF WE SHOULD DO THEM AT ALL. There are many, many projects that should be done if we can do them this week, and should not be done if it'll take a year. Yes, predictability *is* important. At a much higher level, the executives at your young, growing company are borrowing millions of dollars to fund the company until it becomes profitable. Those loans start coming due in three years. Yes, for a young company, it's very survival depends on predicting how long these will take and how much they will cost. Predicting is hard (though certain methods make it much easier), but it's essential.
Re:Yes, TFS is all straw man. *Consistently* wrong (Score:4, Interesting)
Agile is a manifesto. It's pretty much truisms. Hard to argue with. Scrum is just a daily waste of time.
However Agile has some real concrete components: e.g. 'Hire competent enthusiastic individuals'.
So the first thing to do when a prospective boss claims agile is BULLSHIT DETECT! If the place looks to be staffed with anything other than competent enthusiastic individuals, you know they are just lying to themselves and you. Run away. There is nothing worse than Agile done wrong.
Extrapolate further: Competent enthusiastic individuals...server side Javascript. There are no Agile teams running Javascript on the server! None.
Re: (Score:2)
If Scrum does not work for you, you most likely are nor doing Scrum, but some bollocks some one sold you as Scrum. ;)
Or your developers are all pretty poor
Re: (Score:2)
I'm not a manager or coach of any description. Scrum (or something similar) works for us.
I've read about Scrum failing, and I've noticed that there's often things like multi-hour daily meetings or nobody with the authority to decide what's actually wanted. If you do Scrum badly like that, it will almost certainly fail. If you do it well, and you have competent developers, you're likely to succeed.
Re: (Score:2)
There are no Agile teams running Javascript on the server! None.
Thats bollocks. The development methodology has nothing to do with the used technology or architecture.
Re: (Score:3)
> Thats bollocks. The development methodology has nothing to do with the used technology or architecture.
May I differ? Some methodologies are much larger on standardization and common practices. Others are sensitive to security concerns, others use sophisticated continuous integration techniques. Others are prone to excitement with the latest exciting technologies or bleeding edge approaches. Others are extremely sensitive to cost, and focus intently on the specific goal with no resources for out-of-band
Re: (Score:2)
All have effects on the particular technologies and architecture of large projects.
No it does not.
A client server architecture is either necessary or not, and has nothing to do with methodology. ... why not?
Languages and technologies are completely free to chose. Of course you most likely would not use SOAP and code in assembler at the same time. But if you really want
Re: (Score:3)
> A client server architecture is either necessary or not, and has nothing to do with methodology.
If I may differ, _of course_ it does. The communication protocol used among them may be multi-threaded, highly redundant and secure, and robust from single points of failure or short transmisson losses. Those may be critical where the methodology, and the management approach, foster extremely robust individual stages as part of a larger, high reliability structure where every component is considered critical
Re: (Score:2)
All this has nothing to do with the question wether you develop with an agile method (Scrum, XP, Kanban) or water fall or RUP or what ever.
Re: (Score:2)
Agile doesn't endorse methods, it's a manifesto. Agile explicitly states 'people over process'. Which lets out _all_ the rigid methodologies.
I'll grant that in practice 'Agile' most commonly means 'scrum deathmarch with whatever low paid, inexperienced, burnout developers are stupid enough to work for us.' In other words 'not agile'.
My point was when faced with a prospective client/employer who claims 'agile', look out for 'scrum deathmarch'. Don't work there if so.
Re: (Score:2)
I never saw a "scrum deathmarch" project. :D
I only met astonishing bad ScrumMasters lately
In my current project, however, it is ok.
Re: (Score:2)
I don't know you. But the impression I've gotten from your posts is that you've been working one place for 20 some years.
If you've never seen 'scrum deathmarch' you've led a sheltered life. Continuous sprints?
In my experience 'Agile' is _most_ commonly used to justify: 'No spec, no standard, no plan, no testing. Make it up as we go along. Same as we've always done. But now we've got cover. We're not hacks, we're Agile!'
My core point is, when you hear 'Agile' the odds are high that they aren't. Off ha
Re: (Score:2)
I'm self employed.
I switch about every two years my project, but sometimes twice a year.
"'No spec, no standard, no plan, no testing."
Never been in such a project, regardless of "traditional" or "agile".
My core point is, when you hear 'Agile' the odds are high that they aren't.
Well, in my world they are, but I live in Germany/Europe.
Re: (Score:2)
To refresh your memory. I have dual American/German citizenship, but am an American (who drives, drinks and skis like a German). Extensive power industry experience. I have relatives working in IT in Germany. (Particularly banking, we talked a lot of risk management shop.) I know for a fact that Germany is not some ideal world where there are no hacks (proof: SAP) or death marches.
I'd put your experience down to 'power industry' rather than 'Germany'. Rare 'engineer focused' industry.
Re: (Score:2)
Well, right now I work for a software company that does the back ends for car companies, basically everything under the VW umbrella.
Before that I worked for a company that does the school administration software for Bayern and Baden Württemberg. Before that I worked for the software daughter of the internet betting company Tipico.
My power company experiences where btw. mainly waterfall/RUP ... I actually urgent them to Scrum, and later did 2 projects again were Scrum was the main method. They did
Re: (Score:2)
Are you saying you also know how to spot bad 'scrum/agile' shops? That was my main point.
Re: (Score:2)
You know it after the first sprint.
I don't "judge" shops on first glance. To many variables.
Re: (Score:2)
A methodology (manifesto) calls for getting the job done by hiring 'competent enthusiastic individuals'. You won't find those teams running shit tools, 'Competent enthusiastic individuals' are resigned to javascript in the browser, but on the server? I've never met one, rather 'incompetent enthusiastic', the worst kind of incompetent.
Re: (Score:2)
If a company wants to use Node.js on the server, the developers have to comply.
And if they do Scrum while developing in JavaScript, who cares?
And no idea what you have against Node.js. There are plenty of successful projects out there done with Node.js. (I don't do JavaScript, as I don't like it, however it again has noting to do withAgile/not Agile etc.)
Re: (Score:2)
If a company wants to use Node.js on the server, _competent_ developers find someplace else to work. That's the whole point. 'Competent enthusiastic' developers don't use shit tools. Right tool for the job etc.
Re: (Score:2)
I'm not convinced that Node.js is a shit technology.
In my current project we use it for integration tests to mock away SOAP and REST servers. It works good and easy (on any hardware and OS), what do you want more?
As I'm not really fluent in JavaScript, I don't really care about all this new ***.JS stuff ... never interested me. And I don't jump technologies for "more money" ... it is not worth it, in my opinion.
Probably something beyond the project will come up (Score:2)
> For the next sprint, you use as likelely doable number the actual completed SP from thr current/just finished sprint.
We're partially in agreement. I said project management should see this team does about 98 points per sprint.
The team likely does some points that aren't their current main project - a few points supporting last month's project, for example. Some companies include points for things like annual compliance training, which is not part of this project. So we can expect that some of what g
Re: (Score:2)
Some companies include points for things like annual compliance training, which is not part of this project.
But that would be wrong, see below.
Probably around 97, but at least 85, so let's assume 85 in the plan we present to the board."
Then you are cheating yourself, and never will learn the benefits of agile software development.
And, to my frist quote: how do you sell the extra points to your top brass or customer? That does not make any sense at all to have anything with points in a sprint that is not rel
Re: (Score:2)
Fred (Score:2)
Re: (Score:3)
Usually... The goal is to avoid getting "management to help" you with your project, because their favorite tool for a late project is to throw resources at it and ask you for time wasting progress reports.
Attention, All, Attention. Because this project is behind schedule we will be requiring hourly status reports, unless status improves!
Fredrick Brooks was right.... There is no silver bullet (unless you bring your own from home).
Re: (Score:2)
and ask you for time wasting progress reports.
Those come automatically out of Jira or what ever Issue tracker you are using.
Comment removed (Score:5, Insightful)
One worse... (Score:3)
project managers that graduated from the school of flagellation
I've encountered one that it even worse: the Golgafrincham B ark school of project management where you have to hire a business consultant to go around and make sure that the project really is what we need and, after that, to ask whether the proposed solution will satisfy everyone, and after that to... etc. although it did not get quite as far as involving telephone sanitizers. The result was that what should have been a simple one or two month project took over two years, much of which was pointless and e
Re: (Score:2)
I'd add a couple of more.
Project managers that don't understand the details of what they're managing, but want to manage the details. We're on our second project manager in about 4 years and she's great with clients and very personable but she doesn't know anything about the technology we implement.
So when a project has complications and I explain them to here, I can either waste my breath explaining the details of the problem and the details of the underlying technology and why the problem is a problem, o
Yes. (Score:2)
Or maybe no. (Score:2)
Re: (Score:2)
Or maybe no.
Definitely YES, I've rarely come across a more true thing outside of mathematics
Re: (Score:3)
There are very, very few project managers that are actually not detrimental to the production process. And a tiny subset of those is actually helpful. I'm blessed with some of this category (and yes, they cost more than minimum wage... quite a bit more).
The best project managers know that their job is to keep the spice flowing and to give their engineers what they need to be productive. They know how to requisition resources at the right time and in the right amount for the right people from the right sourc
Does nobody read anymore? (Score:5, Insightful)
"The Mythical Man-Month" by Fred Brooks.
This should be required reading once a year for ALL direct and indirect management of any engineering or software development team.
Again with the "Oh, Look at what I found, managing complex tasks is hard!" How many times will we be blessed with the same insight that Mr. Brooks put on paper way back in the 1970's? My guess is "just once more!"
Re: (Score:2)
^^ THIS.
I was about to post a "No Shit, Sherlock" as an answer to "Is Project Management Killing Good Products, Teams and Software?" but your answer is perfect.
Time and time again I seen people / companies _completely_ fail to heed the two most important points of the book:
* Plan to throw one away, you will anyways.
* Adding more people to an already late project just makes the project later
It would be funny if it wasn't so sad how people are completely ignorant of software development history. But I guess
Re: (Score:3)
Lowe is doing even worse than just complaining that planning knowledge work is hard: he's complaining that it is not only impossible, but that it is harmful to try. It's great for consultants if they can convince the customer that is true, because then the customer won't actually hold them responsible for time or dollar budgets, but it is essentially not true. Almost no software development is comparable to building a fusion reactor from scratch, or sending a manned spacecraft to Jupiter, and competent ma
Re: (Score:2)
I've recently decided to revisit that book (after ~20 years) and I was not impressed. For example, the book talks about one man having the overview - seeing the whole picture, making design choices and ensuring consistency in various parts of the project ... the trouble is that the projects now are much bigger, more people are involved, often at different locations and timezones ... I mean, perhaps it can be an interesting read and good in
Re:Does nobody read anymore? (Score:5, Insightful)
I see that AC hasn't actually taken the time to read the book I suggest...
There are plenty of working methodologies for project management, some even work... (smile) ... Brooks doesn't prescribe any specific method of project management, he only describes what to watch out for and why the problem isn't as easy as it first seems, why there is no "silver bullet" to be had. The issues with most PM techniques and technical development processes remains the same as Brooks describes, even though we've changed the names and technologies involved.
In my experience the *real* issue with Project Management is that it is rarely part of the original recipe. Effective PM processes take commitment, work, time and resources and are rarely part of the initial project's planning. What happens is the need for PM suddenly becomes apparent when deadlines and requirements start to slip and management suddenly decides they need to do something. What results is a rush to institute some kind of PM process, that necessarily disrupts the project because now you've added work to the guys in the trenches. They now have to do all their previous work (which is already behind schedule) AND all the reporting and process wickets required by the PM process being mandated. This kind of thing often happens when some small program gains some success, then grows more complex as the need for it grows. The PM process for some small project, doesn't usually support a large development team, but nobody realizes this until it's too late.
There are some really good project management techniques out there, but you have to START the program using them, or suffer lots of pain retrofitting your process to use them. It's hard work...
Re: (Score:2)
"The key thrust of recent years was delegating power down. It was like magic! Improved quality, productivity, morale. We have small teams with no central control. The teams own the process, but they have to have one. They have many different processes. They own the schedule, but they feel the pressure of the market. This pressure causes them to reach for tools on their own."
A lot of 'modern' management schemes, like scrum, are designed to goad programmers to work harder. Even Silicon Valley portrays Scrum as getting programmers to work harder [youtu.be]. That's the whole purpose, it's a stick managers can wield.
The kind of programmers I like working with can self-manage. The only coordination we need is figuring out who will work on what.
Opinions! (Score:1)
Has the blogger got anything to back up his claims or is it just another consultant looking for a gig?
Good project management matters (Score:5, Informative)
It's Project MISmanagement mostly (Score:5, Informative)
At one time I was over a group that did final post production QA on in house programs. The project manager allocated a week for the QA testing of the entire system and I told him that it would take at least four and maybe six weeks. I had no input to the original time allocated. On the very first day of testing I was able to find enough problems that when I wrote them up and turned them over to the project manager that day he turned blue. It was at least three weeks work before he was able to get those fixed and give us another shot at testing. Final outcome was that we were right at the six week point before we were able to report the system clean enough to use.
Re: (Score:2)
Most
Shitty project management is. No news here. (Score:2)
Shitty project management is doing this. But this is no news, is it?
Software stuff is infinetely creative and infinitely complex - it is very easy to screw stuff like this up from a management perspective. Especially since software developers themselves often get predictions about their work wrong - even in an environment where they can control all aspects of their project.
Good project managment is an art and with software it is an exceptionally arcane art. Screw it up even a little and your project goes ha
Price in status reports (Score:5, Insightful)
Re: (Score:2)
That is why you let the issue tracker generate the status report(s).
So if a manager goes maniac he can click the button to get a new report every second if he so desires.
Product Development isn't mathematical. (Score:5, Interesting)
Project Management isn't suited for Product development.
Most project management methods are based on some fallacies.
1. The users of the product knows what they want: The truth is they don't know what they want until they can get their hands on it, and know if what they see if they like it, hate it, or have a some tweaks that are needed. No matter how many meetings you have with static pictures and blueprints. The user just doesn't know what they want until they can get their hands on it.
2. Development of modules have a start time and a complete time: Function X may take 2 days to develop. Because it is prerequisite for function Y. However after function Y is completed and used function Z, You need to go back to function X, to get the data prepped for function Z, but you couldn't put that code in for function Z support until you have completed function Y which needed X. Coding isn't linear, they are parts that needs to be addressed and fixed, causing other parts to be reworked or adjusted.
3. People are interchangeable: A coder is a coder right. Well no. Some of them are really good at doing Database calls, while others are most comfortable with the HTML and JavaScript. While there is an other one who is most comfortable with the Middle tier code. Sure all of them may be able to code all the parts if needed, but for the most part each ones is going to be a specialist in particular parts. This means not all people are used qually or performing each task as efficiently as someone else.
4. People have lives outside the project: While working most people may get called to take a look at a different project (bug fix a previous completed application) they may need to sit in a meeting for a future project. Also they can get sick, have family emergencies...
5. Coders just code uniformly: There is a degree of artistic pride every coder uses. Everyone will approach problems a bit differently, they may be arguing with the Architect for them to be doing something a particular way or they will just ignore, misinterpret, the internal parts of the spec, and just make sure the output meets the specs. So this often creates some conflict because the internal changes may affect something else (timing, system resource, readability...) So we may need to redo the function, or just adapt the rest of the stuff around these changes.
Most PM policies are based on manufacturing processes. Where the goal matches the outcome. Product Development the outcome is usually different then the initial goal.
Re: (Score:2)
Dude just ask a product manager
Re: (Score:2)
Dude ask a product manager [youtube.com]
Re: (Score:2)
It is easy to think that way, but you miss out on many of the benefits of a good project manager. A good PM isolates the team from the politics, manages the scope, and tracks financials-- things programmers and engineers generally hate.
Software really isn't that different from any other creative field in terms of trying to benchmark in real time. It can be done, but with a lot of caveats, disclaimers, and SWAG. Project managers understand that enough to control the process.
Working with bad project manager
Re: (Score:2)
You're describing what sounds like a waterfall approach. Successful software development shops dropped that nonsense twenty years ago.
What are they going to ask next? (Score:2)
"Is HR turning away good job candidates because they are looking for perfect job candidates?"
I feel like some people are refusing to listen to the truth and then after battling with reality for years, they finally arrive to the same conclusion only to announce it like it's some sort of new groundbreaking discovery.
Is this cheating? (Score:3)
The plan that is genuinely comprehensive enough can just be compiled and shipped as the software product, no?
One of my favorite Project Managers (Score:5, Interesting)
Track time estimates, and the 50% slop on top of it. If 1/2 way through the project you have gone through 3/4 of your slop time, you already know you aren't going to make it. If you have only gone through 1/3 of your slop there is a good chance you might actually make it by the 150% time.
Re: (Score:2)
If 1/2 way through the project you have gone through 3/4 of your slop time, you already know you aren't going to make it.
The fallacy there is that you think you can determine when you're 1/2 way through the project.
Burned half the calendar time? Doesn't mean anything.
You think half the development is done? No way to know that.
Estimation technique (Score:2)
Double it and add 30.
FTW Also roughly converts Celsius to Fahrenheit.
Re: (Score:2)
Double it and switch to the next larger unit. Hour becomes day, day becomes week etc.
Re: (Score:2)
Good luck with winning a bid that way :D
Why can you not let people do their own estimates and take them?
the likelihood that anything _you_ add (or remove) improves the accuracy is more or less ZERO.
MBAs are killing Good Products, etc (Score:5, Informative)
One quarter the defense budget got cut and we went from growing 40% to 20%. 20% growth sounds good to you and me. But to the bean counters it was a layoff. That got the expected profits for the quarter back in line at the expense of future growth and morale.
I have to admit, that first layoff got rid of a lot of deadwood. But the second, third, and fourth really killed the company. Those that were either marginal, or not good at politics, got canned. Those that were good at their jobs looked around, said "um, how about no", and left.
I got hit in the 4th layoff, and only got laid off again once since I learned the signs. The second time was a start up failing, I hadn't yet learned how to read a balance sheet.
MBAs don't understand the morale hit they take when they do a layoff. They may say they do, but they don't. I've survived several layoffs, each time morale went to hell and a lot of good people went searching for more stable pastures.
Re: (Score:2)
NO man just ask a product manager [youtube.com]
Embedded Systems (Score:3)
Re: (Score:2)
I also work on systems that combine custom HW, SW, and FW. What works for us is to design the interfaces between the three first. Then that becomes the requirements, and the three teams can then go off and design their subsystems any way they want as long as they meet the requirements.
Simple answer to a stupid question (Score:2)
All one needs to do is... ask Betteridge [wikipedia.org].
Lessons learned (Score:4, Interesting)
We know throwing threads at a problem doesn't work if all you do is end up locking everything. We know that high coupling and low cohesion leads to irreducible complexity. Sharing mutable state instead of doing a little bit of analysis to see what the dependencies are and break down tasks to minimize the reach of these dependencies.
Yet somehow, all these lessons from concrete experience (rather than abstract theory) gets thrown out the door in project management, even from managers who were once software engineers. Project management should be there to facilitate message passing and work stealing queues without trying to force when these things happen.
Not really (Score:3)
If the project is feasible, good developers will get it done regardless of or even despite the plan. The vast majoity of plans have problems because they want a man-year's worth of code from three months of work, which means it was never a good plan. But poor project management can turn a bad plan into a disaster by refusing to acknowledge the delay. I've been in meeting that pretty much involved badgering the developers until our estimates said we'd deliver. Oddly enough those "revised" estimates never came true...
AGILE WORKS EVERY TIME (Score:5, Funny)
Whoa man all the cool hip project managers Agile development [youtube.com] as it solves 100% of the problems 100% of the time. It makes you grow a beard and transports you to a hipster Silicon Valley coffee shop with music playing that hasn't even been written yet complete with groupies watching you code.
That author needed a deadline on the article (Score:2)
Wouldn't have hurt if the author had been given a project plan and a deadline for that article.
Maybe I'm getting old and impatient but it went on for far too long.
Great sentiment and I have seen many of the effects mentioned, but hey, summarize.
Waterfall and Rational Rose All the WAY!!!! (Score:2)
What is this Theory X?
I am still using the Waterfall Model [google.com] and IBM's Rational Rose Modeler. [google.com] Does software development get any better?
Bad PMs kill projects (Score:3)
The difference between an effective and ineffective PM is astounding in most places I've worked. On one end you have a forceful PM who will beat up their resources and harass their managers until the work is done. On the other are the PMPs clinging for dear life to their copy of the PMBOK who are unable to get anyone to do what they want.
You can tell a PM isn't so great when you hear the exact same phrases and jargon repeated in the exact same order on endless conference calls. [1] I'm not saying it's easy either...I could never do that job because I can't coerce people to do what needs to be done. And when it comes down to it, that's a PM's only job...well, that and checking the boxes and filling out Gantt charts.
[1] I swear that one PM I worked with would say "Good morning, who just joined the call?" in the EXACT same tone, rhythm and texture at the sound of every beep on conference calls. It was like a machine!
BAD Project Management kills everything (Score:4, Interesting)
On anything with more than 5-6 people on a team, a project manager is a necessity. It is inefficient in first-order terms, but keeping people focused on what they are good at (and a dedicated person managing scope) dramatically improves productivity. Generally, less than 10% of hours should be in project management.
Bad project management is a different beast. Bad project managers add needless complexity, waste time, and draw focus to aspects of the project that participants cannot control.
Re: (Score:2)
Actually so small teams don't need a project manager and most of the time they run Scrum/XP anyway.
The project manager might be helpful in coordinating teams, especially if they belong to different companies, suppliers and customers.
If a software team needs a project manager, I would fire the team and get better developers.
Re: (Score:2)
The technical coder is effectively a project manager in your example-- the problem isn't that developers can't coordinate among themselves, but rather that it becomes less efficient as project complexity increases. If you have a team of superstars you can pull it off, but you are stuck finding superstars for each position. There are places for B-Team players on most projects.
Doing it mechanically (Score:3)
They're trying to reduce everything to statistics and numbers, like Robert McNamara did in Vietnam. [pbs.org]
It's trying to make sense of something they don't really understand - the human element. The chaos. Motivation. Leadership. Ability.
"If you can't measure what's important, what you can measure becomes important."
What kind of article is this? (Score:2)
In an agile team using Kanban, for example, there is no “project” at all—there’s only a continuous stream of value-delivering work, prioritized by someone who keeps a finger on the pulse of the customer and validated with actual customers.
Yes, we use Kanban, and we deliver a continuous stream of value-delivering work, prioritized. However, the prioritization did not come from someone but an entity of 3, composing of the Project Manager, Product Manager and the Product Owner. These 3 negoti
A good management attack ... (Score:2)
Re: Well... (Score:2, Insightful)
Some supervision is required, but I know the project I'm working on right now would be better off if we fired everyone between Sr. Director and SVP (half the Directors too!).
Re: Well... (Score:5, Insightful)
Coordination is required. Cutting the red tape is required. Supervision is not.
Management should finally find out that they're a supporting role to those that produce instead of going on a micromanaging power trip.
Re: Well... (Score:4, Interesting)
My best (former) manager (I was developing Oracle software for a State agency) said that his number one job was to be an umbrella to keep the shit from falling on us and distracting us
When I became a software development manager, I saw my number one job as keeping the developers from being drug off into endless project meetings and being kept away from doing their work.
SCRUM was my favorite tool, with the daily standup and pre/post sprints meetings were my source for all information to deliver back to the project manager(s).
Project management can be applied to software development, BUT clueless fucking PM's who think that their #1 job is keeping everybody scheduled for project status meetings are going to blow the whole deal.
Re: (Score:2)
My best (former) manager (I was developing Oracle software for a State agency) said that his number one job was to be an umbrella to keep the shit from falling on us and distracting us
I think he's now working for us, these words sound quite familiar.
Re: Well... (Score:5, Interesting)
My favourite manager (now retired) had the same philosophy. You'll find a similar theme amongst most people's favourite bosses.
He was an ex-Army (AU) warrant officer and wouldn't hesitate to rip you up like a drill sergeant if it was your fault, but equally wouldn't hesitate to throw it back upstairs if it were a problem with senior management or sales. If any customers were being unreasonable with his engineers, he'd practically teleport to site, sit everyone down, look the customer in the eye and calmly ask them what their business case was for being difficult with a vendor.
He also had a mostly hands-off PM style, he'd just bump into people during breaks at random points, ask a couple of questions, move on. Ask him where the pieces of project were at and he could list them off like a human Gantt chart just based on those queries. But woe betide you if you didn't inform him of any looming problems before they became serious, or if you tried to push blame away. If you came to him with a blunt statement along the lines of "I fucked up, here's the issue, I think this could solve it", he'd bend over backwards to get it sorted.
I've since tried to model my own management style after his - definitely not as successfully.
Re: (Score:2)
A million times this! I had a boss like that for 5 years - what a bliss! At a certain moment many employees started leaving the company and one of them asked us (my team) "Why are you still here?". We looked at each other and said in one voice "Because of our boss and the excellent atmosphere in the team".
Leaders eat first and get the best mate but when the lion jumps the fence they meet it head on....or that's how it was for most of human history until we invented modern economy. Real leaders do not throw
Re: (Score:2)
> Coordination is required. Cutting the red tape is required. Supervision is not.
A certain amount of supervision can be critical. I recently spent long chat with a developer walking through their need for exploring some complex issues that existed only in their theories, not in practice, and having to take away the hardware resources they wanted to use for research of why it didn't fail in the real world.
Re: (Score:2)
Agile development can be quite useful. Sadly, most project managers confuse it with not having to do their work and think "agile" means "the programmers have to change the project daily when I come up with new shit I didn't think about before".
Shitty programming languages play a big role. (Score:3, Informative)
There's the stupid saying that I'm sure we've all heard, "A bad craftsman always blames his tools!". The reality, though, is that some tools are just fucking awful, no matter who is using them. Even in the hands of the best expert to have ever existed there are tools that won't work well at all.
We see that happening with software development. As we've seen more shitty tools like Ruby, JavaScript and even Rust be used, we've seen software quality decline steeply. Such software is often slow. It's bloated. It
Re: (Score:2)
Recognition that there actually are different kinds of thangs used to program with leads to widespread use of actually useful languages such as Cobol, C, C++, Perl and Javascript, all popular and none with a design philosophy that overrides real-world coding.
Re: (Score:2, Informative)
A good craftsman uses tools that are appropriate to the job.
I am very unimpressed with 10,000 pages documenting how the software project was managed, when there is nary a page of documentation on how the end-user is going to use the software in question.
Seeing scenarios like that occur umpteen times, in projects led by those who alleged are qualified in PM, more or less soured me on PM. It wasn't until I took the time to intensively study PM, that I understood why that most of those projects were led by bl
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
And this is what's wrong. Most of those managers could easily be replaced by a Magic-8-ball.