Hey, I would have loved to port it to the Amiga and to the Mac as well. But I was already gone from FTL by the time the Atari ST port happened. Sigh...bruce..
This Christmas I'm going to buy a stack of The Mythical Man-Months and leave them on all the managers' desks around here...
I did that once, some years back, on a project that I had been brought in to 'rescue'. I ordered 30 copies of TMMM and gave them to everyone involved in the project from top management down to the lowliest IT engineer.
Sadly, I don't think that anyone actually read them. You can lead a horse to water . . ...bruce..
Actually, there are quite a few books that discuss IT project failure (including runaways); here's a recommended reading list that I keep on one of my web sites (though you'll have to wait until the server recovers)...bruce..
The difference (I'll bet) is that the prior link included enough of the original article for the vast majority of slashdotters to just read that and then dive into the discussion.
That could well be the case. My server appears to be topping out around 1550 simultaneous users (that's the highest I've seen via my SiteMeter info); I honestly don't know whether the previous article got up that high...bruce..
Great post. You'll find a less-general version of Renn's Law in The Art of Systems Architecting by Maier and Rechtin, in Appendix A ("Heuristics for systems-level architecting"): "In architecting a new software program all the serious mistakes are made on the first day." (p. 271). I have quoted that many, many times.
I like your list of key problems. I'm currently writing/editing a book (Pitfalls of Modern Software Engineering) and looking for additional contributors. If you're interested, drop me an e-mail (bwebster@bfwa.com)...bruce..
Trust me, the original project manager's initials weren't "BW". But that's a good catch. I chose "Bob Winsom" because I couldn't find anyone by that name via Google...bruce..
I'm not sure how carefully the manager you quote read my post, since some of your 'quotes' are wrong (as well as the apparent assumptions as to my own role), and some of the manager's responses are non sequiturs.
I was brought in from the outside specifically to conduct a review and summarize my findings in a memo for one specific person in upper management at BigFirm who was above the FUBAR project and who had grave concerns about it, given that at that point the project was years late and millions over budget, and which showed few signs of making it into production anytime soon.
I was not one of the "coders" -- I was not even a project member -- and I certainly wasn't a "new kid out of college"; I graduated with BSCS in 1978; my first programming languages were 360 assembly, PL/1 and FORTRAN, and by the time I conducted this review, I had personally done professional software engineering (including project management, architecture, and consulting) in a wide range of operating systems and programming languages over quite a few fifferent industries.
The ABC consultants, to a person, were likewise very senior software engineers with many years of hands-on coding experience and well-established track records of successful project delivery.
I'm surprised that an IT manager doesn't know what "very fragile code" means. "Fragile code" means that efforts to modify one section of code -- to fix a bug, add functionality, or improve performance -- frequently results in the code "breaking" elsewhere, usually in multiple places. The opposite of "fragile code" is "robust code".
The memo states clearly that previous architects had left (not "project managers"); the problem was that the FUBAR project manager (with no technical background) kept driving them off and, as the memo notes, fancied himself a software architect.
The syndrome of "kingdom building" through increased head-count has long been a major cause of IT project failure; in this case, there were far too many programmers than the problem actually required.
As for my "amateur" status, I'll simply point here; is the manager willing to do the same? (Sorry about the server problems; I'm raising hell with my hosting service, given what I pay each month for a dedicated server.)..bruce..
Remember that this was a memo written for upper management at BigFirm, not a published case study. What caught my attention, when I rediscovered the memo a few days ago, was how pervasive, broad and serious the problems were, all in one project.
As the first paragraph of the post notes, the project was eventually killed...bruce..
Come on now, COBOL isn't that bad.:P. But seriously Java isn't the language you would use for high performance but rather high portability. That says a lot about how bad the original code was.
The point of that observation was exactly that: a rewritten version in Java, running on a laptop (and we're talking about a laptop several years ago), was faster than the original implementation on much-higher-powered hardware. It was also nearly 2 orders of magnitude smaller (in LOC)...bruce..
I'm a bit stunned myself. The article had been picked up by reddit and FARK prior to Slashdot, but even so, I've had another post on my blog previously linked to by Slashdot without server problems. I've already contacted my hosting company to find out what's going on.
I've certainly seen that pattern as well, but it's not what happened in this case. In this case, the development team was primarily in-house through most of the project. The consultants were brought in by BigFirm late and in small numbers...bruce..
I have a dedicated server and have had slashdotted postings before that haven't brought the server down. I've e-mail the support team to see what's going on...bruce..
Given the vagaries of university curricula, not to mention the ever-present inter-departmental fighting and politics, I'm not surprised that would be a lot of science departments that would not require a programming class of some kind.
Which is not to say that they shouldn't. I note that my own alma mater (Brigham Young University) has a required course in 'Computational Physics' for all Physics majors, but that is primarily solving integrals and differential equations using MAPLE...bruce..
That should be "the Peter Principle", not "the Peter Principal". Sorry about that; "Principal" happens to be my own job title, and that spelling is sort of hardwired into my fingers...bruce..
Thanks for all the great comments, though I suspect many of you didn't ready anything more than the brief extract posted here at Slashdot.:-) Because certain themes keep coming up again and again, I thought I'd address them in a single post (I also posted this over at my website).
Here's a response to the main themes that I see coming up there.
The Dead Sea effect isn't unique to IT. True enough, though I could say the same thing about just about any project management issue regarding IT. What is unusual about IT (shared with other engineering disciplines) is the degree to which individual talent and other factors affect productivity and quality. And what is unique about IT (as opposed to, say, civil / mechanical / chemical engineers, architects, etc.) is that there is no standard (state-run) professional certification, so there is no assurance of minimum education and competency.
This is obvious/common sense/trivial. So are most of the problems in IT. Fred Brooks and Jerry Weinberg pretty much nailed down all the essential issues in IT project and personnel management more than 30 years ago; yet, amazingly, the problems haven't all gone away! There is a profound lack of professional and institutional memory in IT; almost everyone who writes about IT project/personnel management (myself included) is looking for new ways to cast or explain the core issues in a touching hope that maybe this time someone will actually listen and fix them.
The Dead Sea effect is just the Peter Principal (or a corollary thereof). No, it isn't. The Peter Principal is that a given person rises to her/his level of incompetence (I'm actually old enough to remember when 'the Peter Principal' first came out). This has nothing to do with promotion within the IT organization; it has to do with self-selected removal from that IT organization, not due to a lack of promotion or opportunity, but just because there are greener pastures elsewhere.
Not all IT shops are like this. I would certainly hope so. In fact, there are IT organizations where just the opposite occurs; the quality of the IT engineers is quite high, and engineers who are mediocre or disruptive either don't get hired or don't last long if they are. I worked in one such IT group (Pages Software) for five years. During that time, we had only one voluntary departure (the network admin); we had two others who were dismissed due to problems, and a few others who were (painfully) cut in downsizing.
Not everyone 'left behind' is incompetent. Again, this syndrome doesn't apply to all IT groups, and it doesn't apply to the same extent to all IT groups. Turnover in IT personnel is common (though it can be reduced by intelligent management), and just because good engineers have left a given IT group doesn't mean that the rest are, in fact, residue. What I'm talking about here is a very real syndrome, typically found in large corporations and government organizations, but it's certainly not universal.
The IT hiring process is broken. Amen. Not only is the IT hiring process broken in many organizations, the entire approach to IT is often broken. It is rife with empire-building, 'heroic' project management, and an 'interchangeable code monkeys' mindset. As mentioned in the comments
"IT engineers." Amazing how worthless the word engineer is these days. Can't wait until high school teachers are calling themselves doctors, because hey, they technically are! I'm painfully aware (and have written about) the difference between true engineers (civil, mechanical, chemical, etc.) and people who work in IT. I use the term "IT engineers" as a useful catch-all phrase for the full range of people who work in IT (including programmers, architects, DBAs, network admins, QA personnel, and so on).
I someday hope that "software engineering" will be a real profession -- but on the other hand, that has legal and professional consequences (e.g., state boards, state licensing, risk of malpractice) that I suspect most people in IT wouldn't want to touch...bruce..
Where do the more talented and effective ones go? Google? Only if they can get in.:-)
Depending upon the business cycle and their own inclination, they either go to do startups (trading security for fun/intensity) or they become consultants (trading security for a multiplier on their salary). At least, that was my observation...bruce..
There needs to be a better salary distribution. Good network administrators are like world class composers. Amen to that, Roy. When I was at Pages (as CTO), I had constant fights with the CFO and the CEO over the pay for our network administrator (Sean Church) and told them it would take several people to replace him. I was right, too. Sean left Pages in early 1995, and it took three of us -- myself, the VP of Engineering, and the Director of Quality -- to pick up the slack...bruce..
ROTFL. I've been coding for 34 years (actually, I can make arguments back to 1971 or even back to 1969, but I'll go for consecutive years). Do you know how often I have heard the "programming is dead/program generators will do it all" mantra? (Here's on clue, an article from 27 years ago about "The Last One", as in "the last program that anyone will ever need to write".) This is a canard that gets dragged out every decade or so, and then is quietly put away again.
As for evolutionary computation -- for which I actually hold out great long-term hopes -- let me know when you can 'evolve', say, a word processor or a mission-critical corporate business application.
And since COBOL and Fortran still aren't 'obsolete' and still run a sizable percentage of the world's applications, I'm not sure how soon C and C++ will become 'obsolete'...bruce..
Slashdot Mirror
Cool -- I'll try to keep writing interesting blog posts. :-) And thanks for the submission, though I'm not sure how happy my hosting company is.
..bruce..
Also check out my new column over at Baseline (baselinemag.com).
Hey, I would have loved to port it to the Amiga and to the Mac as well. But I was already gone from FTL by the time the Atari ST port happened. Sigh. ..bruce..
This Christmas I'm going to buy a stack of The Mythical Man-Months and leave them on all the managers' desks around here...
I did that once, some years back, on a project that I had been brought in to 'rescue'. I ordered 30 copies of TMMM and gave them to everyone involved in the project from top management down to the lowliest IT engineer.Sadly, I don't think that anyone actually read them. You can lead a horse to water . . .
Thanks for the kind words about SunDog. :-) ..bruce..
Lunarpages. ..bruce..
Actually, there are quite a few books that discuss IT project failure (including runaways); here's a recommended reading list that I keep on one of my web sites (though you'll have to wait until the server recovers). ..bruce..
That could well be the case. My server appears to be topping out around 1550 simultaneous users (that's the highest I've seen via my SiteMeter info); I honestly don't know whether the previous article got up that high.The difference (I'll bet) is that the prior link included enough of the original article for the vast majority of slashdotters to just read that and then dive into the discussion.
If my server ever recovers, go look at this earlier post defining and discussing the "thermocline of truth". ..bruce..
Aaron:
..bruce..
Great post. You'll find a less-general version of Renn's Law in The Art of Systems Architecting by Maier and Rechtin, in Appendix A ("Heuristics for systems-level architecting"): "In architecting a new software program all the serious mistakes are made on the first day." (p. 271). I have quoted that many, many times.
I like your list of key problems. I'm currently writing/editing a book (Pitfalls of Modern Software Engineering) and looking for additional contributors. If you're interested, drop me an e-mail (bwebster@bfwa.com).
Trust me, the original project manager's initials weren't "BW". But that's a good catch. I chose "Bob Winsom" because I couldn't find anyone by that name via Google. ..bruce..
I also strongly recommend The Daily WTF, and Alex Papadimoulis (who runs WTF) and I have linked to and commented on each other's posts.
:-) ..bruce..
Also, remember that this was a professional memo written to a high-level manager at BigFirm. It wasn't written to be amusing.
I'm not sure how carefully the manager you quote read my post, since some of your 'quotes' are wrong (as well as the apparent assumptions as to my own role), and some of the manager's responses are non sequiturs.
..bruce..
I was brought in from the outside specifically to conduct a review and summarize my findings in a memo for one specific person in upper management at BigFirm who was above the FUBAR project and who had grave concerns about it, given that at that point the project was years late and millions over budget, and which showed few signs of making it into production anytime soon.
I was not one of the "coders" -- I was not even a project member -- and I certainly wasn't a "new kid out of college"; I graduated with BSCS in 1978; my first programming languages were 360 assembly, PL/1 and FORTRAN, and by the time I conducted this review, I had personally done professional software engineering (including project management, architecture, and consulting) in a wide range of operating systems and programming languages over quite a few fifferent industries.
The ABC consultants, to a person, were likewise very senior software engineers with many years of hands-on coding experience and well-established track records of successful project delivery.
I'm surprised that an IT manager doesn't know what "very fragile code" means. "Fragile code" means that efforts to modify one section of code -- to fix a bug, add functionality, or improve performance -- frequently results in the code "breaking" elsewhere, usually in multiple places. The opposite of "fragile code" is "robust code".
The memo states clearly that previous architects had left (not "project managers"); the problem was that the FUBAR project manager (with no technical background) kept driving them off and, as the memo notes, fancied himself a software architect.
The syndrome of "kingdom building" through increased head-count has long been a major cause of IT project failure; in this case, there were far too many programmers than the problem actually required.
As for my "amateur" status, I'll simply point here; is the manager willing to do the same? (Sorry about the server problems; I'm raising hell with my hosting service, given what I pay each month for a dedicated server.)
Remember that this was a memo written for upper management at BigFirm, not a published case study. What caught my attention, when I rediscovered the memo a few days ago, was how pervasive, broad and serious the problems were, all in one project.
..bruce..
As the first paragraph of the post notes, the project was eventually killed.
Come on now, COBOL isn't that bad. :P. But seriously Java isn't the language you would use for high performance but rather high portability. That says a lot about how bad the original code was.
The point of that observation was exactly that: a rewritten version in Java, running on a laptop (and we're talking about a laptop several years ago), was faster than the original implementation on much-higher-powered hardware. It was also nearly 2 orders of magnitude smaller (in LOC).I'm a bit stunned myself. The article had been picked up by reddit and FARK prior to Slashdot, but even so, I've had another post on my blog previously linked to by Slashdot without server problems. I've already contacted my hosting company to find out what's going on.
I've certainly seen that pattern as well, but it's not what happened in this case. In this case, the development team was primarily in-house through most of the project. The consultants were brought in by BigFirm late and in small numbers. ..bruce..
I have a dedicated server and have had slashdotted postings before that haven't brought the server down. I've e-mail the support team to see what's going on. ..bruce..
"Bob Winsom" is a pseudonym. The individual referenced was the FUBAR project manager at BigFirm. ..bruce..
Given the vagaries of university curricula, not to mention the ever-present inter-departmental fighting and politics, I'm not surprised that would be a lot of science departments that would not require a programming class of some kind.
..bruce..
Which is not to say that they shouldn't. I note that my own alma mater (Brigham Young University) has a required course in 'Computational Physics' for all Physics majors, but that is primarily solving integrals and differential equations using MAPLE.
That should be "the Peter Principle", not "the Peter Principal". Sorry about that; "Principal" happens to be my own job title, and that spelling is sort of hardwired into my fingers. ..bruce..
Thanks for all the great comments, though I suspect many of you didn't ready anything more than the brief extract posted here at Slashdot. :-) Because certain themes keep coming up again and again, I thought I'd address them in a single post (I also posted this over at my website).
Here's a response to the main themes that I see coming up there.
The Dead Sea effect isn't unique to IT. True enough, though I could say the same thing about just about any project management issue regarding IT. What is unusual about IT (shared with other engineering disciplines) is the degree to which individual talent and other factors affect productivity and quality. And what is unique about IT (as opposed to, say, civil / mechanical / chemical engineers, architects, etc.) is that there is no standard (state-run) professional certification, so there is no assurance of minimum education and competency.
This is obvious/common sense/trivial. So are most of the problems in IT. Fred Brooks and Jerry Weinberg pretty much nailed down all the essential issues in IT project and personnel management more than 30 years ago; yet, amazingly, the problems haven't all gone away! There is a profound lack of professional and institutional memory in IT; almost everyone who writes about IT project/personnel management (myself included) is looking for new ways to cast or explain the core issues in a touching hope that maybe this time someone will actually listen and fix them.
The Dead Sea effect is just the Peter Principal (or a corollary thereof). No, it isn't. The Peter Principal is that a given person rises to her/his level of incompetence (I'm actually old enough to remember when 'the Peter Principal' first came out). This has nothing to do with promotion within the IT organization; it has to do with self-selected removal from that IT organization, not due to a lack of promotion or opportunity, but just because there are greener pastures elsewhere.
Not all IT shops are like this . I would certainly hope so. In fact, there are IT organizations where just the opposite occurs; the quality of the IT engineers is quite high, and engineers who are mediocre or disruptive either don't get hired or don't last long if they are. I worked in one such IT group (Pages Software) for five years. During that time, we had only one voluntary departure (the network admin); we had two others who were dismissed due to problems, and a few others who were (painfully) cut in downsizing.
Not everyone 'left behind' is incompetent . Again, this syndrome doesn't apply to all IT groups, and it doesn't apply to the same extent to all IT groups. Turnover in IT personnel is common (though it can be reduced by intelligent management), and just because good engineers have left a given IT group doesn't mean that the rest are, in fact, residue. What I'm talking about here is a very real syndrome, typically found in large corporations and government organizations, but it's certainly not universal.
The IT hiring process is broken. Amen. Not only is the IT hiring process broken in many organizations, the entire approach to IT is often broken. It is rife with empire-building, 'heroic' project management, and an 'interchangeable code monkeys' mindset. As mentioned in the comments
I someday hope that "software engineering" will be a real profession -- but on the other hand, that has legal and professional consequences (e.g., state boards, state licensing, risk of malpractice) that I suspect most people in IT wouldn't want to touch.
Depending upon the business cycle and their own inclination, they either go to do startups (trading security for fun/intensity) or they become consultants (trading security for a multiplier on their salary). At least, that was my observation.
ROTFL. I've been coding for 34 years (actually, I can make arguments back to 1971 or even back to 1969, but I'll go for consecutive years). Do you know how often I have heard the "programming is dead/program generators will do it all" mantra? (Here's on clue, an article from 27 years ago about "The Last One", as in "the last program that anyone will ever need to write".) This is a canard that gets dragged out every decade or so, and then is quietly put away again.
As for evolutionary computation -- for which I actually hold out great long-term hopes -- let me know when you can 'evolve', say, a word processor or a mission-critical corporate business application.
And since COBOL and Fortran still aren't 'obsolete' and still run a sizable percentage of the world's applications, I'm not sure how soon C and C++ will become 'obsolete'.