Slashdot Mirror
Is Project Management Killing Good Products, Teams and Software? (techbeacon.com)
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."
I've been around for a number of years in the dev trade. I've seen good and bad projects. When project management is done well it makes a world of difference. Everyone knows what needs to be done without needing three meetings a week just to figure out who is working on what. The deliverables get clearly defined, and change management is enshrined and accounted for. Working in this environment is awesome. Now, do project management badly and your project WILL be over budget and over schedule. Nobody will be happy and it will be a crap job. Nobody will be especially clear what the deliverables are because change management is not accounted for and you have moving targets. The team spends more time finding who to blame than just fixing the problem. My opinion - if you are using the wrong tools, you'll have wrong project management. (i.e. Asana is a task tracker, not an asset manager, resource planner, time log, or credential manager... Task tracking is only part of the equation).
Project mis-managers make nice pretty Gantt charts to show the C-suite, but try to actually use them to plan and manage a project. Gantt and PERT were developed as REPORTING visuals during the Polaris missile program to show Congress how things were working. I got a degree in Industrial and Systems engineering before being seduced by computers and during my entire career I never saw any Project Manager that understood that. What's worse they would pull times for task completion out of somewhere the sun never shone.
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.
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's hard to maintain. It's just an awful experience for users and programmers alike.
Rust is perhaps the epitome of this phenomenon. In my opinion it takes the worst aspects of the major programming languages, adds in confusion, adds in hype, and the results are a stunning disappointment. Look at how little has been accomplished on Servo, a new web browser engine specifically written in Rust. I've been tracking its progress for a couple of years now, and it's very underachieving, I think. I'd say it's no better than a late-1990s era browser engine, and in some ways it's worse.
I wish we'd see programmers go back to the days of using languages like C, C++, and Delphi. At least that software worked well, it performed well, it was usable, and allowed developers to create and maintain the software within reasonable time frames. It's a far cry from the JavaScript or Ruby projects we see today that deliver a crappy user experience, and it takes the programmers forever just to get something built.
I first hit this in the 80's. Our company was the first to use microprocessors to replace walls of computers with boxes maybe 3 cubic feet (1x1x3), that by the way did 10 times the work the walls of computers did.
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.