Heroic Programming
Heroic ProgrammingHeroicProgramming, usually a pejorative term, is used to describe the expenditure of huge amounts of (coding) effort by talented people to overcome shortcomings in process, project management, scheduling, architecture or any other shortfalls in the execution of a software development project in order to complete it. HeroicProgramming is often the only course of action left when poor planning, insufficient funds, and impractical schedules leave a project stranded and unlikely to complete successfully. It is highly probable that more projects are, in fact, completed by acts of HeroicProgramming than by proper analysis, design, architecting, planning, scheduling, budgeting and implementation combined. Many people (especially methodologists and consultants in the business, of which I am one) would disagree with this last statement, but in my experience, this sad fact is most likely true and is one of the most important obstacles that the software design and engineering community must overcome.
HeroicDebugging on the other hand, is more, well, Heroic... -- TarongaZooStory
HeroicProgramming is frequently used by GradyBooch in his writings, however its exact origin is unknown to me.
Another area where I have seen HeroicProgramming come into play is where a software developer decides on his own (i.e., without a specific user requirement) to add something because it is "easy to do". I have seen considerable time wasted and delivery delays incurred fixing something the customer never asked for. YouArentGonnaNeedIt! -- WayneMack
For an article on this topic, see "Enough About Process: What We Need are Heroes," http://www.satisfice.com/articles/enough_about_process.pdf. This was written by JamesBach back in 1995 for IEEE Software. -- BretPettichord
SteveMcConnell talks about this topic from a process standpoint, except he calls it CommitmentOrientedDevelopment?. Contrast to ProcessOrientedDevelopment?. This is an editorial from IEEE Computer, March/April 2000. "Cargo Cult Software Engineering" http://www.computer.org/software/so2000/pdf/s2011.pdf -- KenLiu
The link above is broken, there's one that work in the page about CargoCultSoftwareEngineering
"... probable that more projects are, in fact, completed by acts of HeroicProgramming ..."
I fear this may be true. I am sure that the following is true: "more projects have failed through the insufficiency of HeroicProgramming than from any other single cause."
When I reflect on my failed projects, it seems that many/most failed from trying to do too much in too little time. Even the best hero (and we know who he is) can't really produce good software forever doing 80 hour weeks. Stopping to think what not to do could have saved some of those projects. -- RonJeffries
Failure due to "trying to do too much in too little time" is often merely a symptom of the problem of MediocreManager?, which just a subset of the problem of MediocreTalent?, which in-turn is a subset of HopelessApproach?.
When I look back on my own failed projects I see squandered time rather than lack of time. I see projects that could easily have been built by a handful of good programmers in 6 months attempted unsuccessfully by legions of programmers, project managers, program managers, process managers, configuration managers, u.i. designers, business analysts, product marketing managers, directors, vice-presidents, etcetera, spending tens of thousands of hours squabbling in conference rooms and tens of thousands of hours producing never-to-be-read paperwork, in noisy five-acre cube farms, housed inside hermetically sealed buildings with stale air, cheap lighting, and bad coffee.
But I'm not bitter. :-) The dental plans were pretty good.
"Too busy mopping up to fix the leak" is another related expression. People become obsessed with testing and fixing, papering over the cracks, etc. Although the fundamental flaws are known, it's usually easier to justify a quick fix. -- BrianSyme
TooBusyBailingToFixTheLeak? sounds better.
One time I was brought in on a large project to perform triage and find out the reasons it was over a year late and nowhere near close to completing. The cause of my DilbertMoment: the first thing I asked for was the project plan, and after much squirming and avoidance they finally told me that they were so busy completing the projects (over 50 coders, heads down in the cubicles) that they had no time to update the project plan so it was about 9 months out of sync and had no bearing on reality. This is commonplace in my experience and usually results from lack of good project management skills on the part of the project leads.
From what I have seen, real project planning and management is thrown out the door because it fails to meet expectations and doesn't tell people want they want to know when they want to know it (PM usually tells you that you are in trouble after it's too late to do anything). One concept I have been interested in is ProjectVelocity, or the measurement of the rate at which scheduled events in the project are taking place. For example, if you are driving to New York at 60 miles an hour, and you have 60 miles to go you will naturally think you'll get there in an hour. But 3 miles away, you'll slow to 3 miles an hour and you'll still have an hour to go. Currently, most project management methods do not measure this and consequently often misforecast the time and effort that goes into a project, especially since software systems are prone to the "last 10% takes 90% of the time" syndrome. ProjectVelocity measurements can identify when things slow down soon after they happen and allow for more realistic forecasting. It's still not a panacea and will not help projects that are deep in the throes of a misguided attempt to finish the project through HeroicProgramming, but it's a start.
Having been on projects where the project plan got out of sync very quickly (or the answer to "Show me the project plan.", was "Project plan? What's a project plan?"), I'd like to see a PatternLanguage of ProjectPlanningPatterns?. -- KatyMulvey
Maybe I'll take a partial stab at that this spring or summer, Katy, and I'll post them here for critique. Others interested contact me arc@acm.org and we can collude. I think it is different from the OrganizationalPatterns and RiskReductionPatterns?.
About triage and HeroicProgramming, a little CultureBuildingStory? I kept hearing at EvansAndSutherland? (a HeroicProgramming heaven - i.e. lots of it) was when, way late into a big expensive project, the project manager was told a particular card was being difficult to test. He asked about the other cards of the same type - "They are OK, it is only this one card we have spent several weeks (of 15-hour days) unsuccessfully trying to debug." After some more questions, the PM asked to see the card. He took it and broke it over his knee. "It's a broken card," he said. "Use a different one."
Illustrations of the story? Haven / heaven / hell of HeroicProgramming, project management triage, value of sacrificing expensive hardware for even more expensive labor. Probably others. Also shows impact of CultureBuildingStory? telling (there is even a book on this, but I don't recall its name) -- AlistairCockburn
On ChryslerComprehensiveCompensation, towards the end, we got into a bit of HeroicProgramming. We pushed and pushed, worked zillions of hours of overtime. Then we got finished, took a few days off, and came back to work. We looked at each other and decided we had been getting about 30 effective hours out of our 60-80 hour weeks. This was about the millionth time I learned that lesson.
When the chips are down, work smarter, not harder. And while you're at it, see NotEnoughTime. -- RonJeffries
Alternatively, you might wanna consider you've just had enough Ruffles and call it a day, which is just another shot at the same thing. :)
In response to the problem with project plans that Katy describes, I've adopted (and adapted) Ward's WorkQueue strategy (from his Episodes pattern language, see http://c2.com/ppr/episodes.html). It's a low-overhead alternative to task-oriented Gantt charts.
A WorkQueueReport? is a prioritized list of high-level requirements, correlated with developer responsibilities and expected completion dates. It helps to ensure that the most important things are worked on first.
I show clients how to use an Excel spreadsheet to maintain their Work Queues. It's definitely an example of DoTheSimplestThingThatCouldPossiblyWork -- JamesCollins
I'm somewhat unconvinced of the downsides of HeroicProgramming. I understand that, in general, HeroicProgramming can be a bad thing to encourage. However, I work at a company with a Hero Culture - I'd say 80% people in department would be the absolute AlphaGeek if they worked elsewhere. We have done the proverbial "shove ten pounds of s--- into a five pound bag" - creating a working DMT DSL implementation using less than 1/10th the memory that our competitors use (thus smaller die size and less cost, good things). And the reason we do so is because most everyone casts themselves as a hero - the impossible is expected of each of us and we step up to the plate and knock it into the stands. It is a team culture in a very macro sense: everyone is good friends, we hang out together, watch each others kids, etc. But in the office, it is very competitive, a game of "Who can do the coolest thing" with a new winner every week. I dig the culture, and I accept the fact that it isn't conducive to newcomers, so eventually it will have to be abandoned, but in the meantime I'm enjoying every minute of working there, and working with a team that is extremely good at what it does despite our internal chaos. -- TimBornemisza?
How much skill overlap does your group have? If you have a low TruckNumber, you can easily see the problem with HeroicProgramming - what happens when you lose your hero? You also mention the lack of newbie-friendliness of the culture; and then there is the problem when your geeks decide to GetaLife -- PeteHardie
I like the condescending tone above. I see it very often lately :) Hmmm, I remember when I was younger I sometimes worked 24+8 hours in 2 days. I got my life, and I learnt a lot of stuff then, never regret it. I sometimes regret that I can't do it anymore. Way to go, Tim. -- CostinCozianu
I suspect that TimBornemisza? isn't really talking about HeroicProgramming as it's defined here by the original writer. TimBornemisza? tells of heroes performing heroic feats, but his story lacks the elements of poor planning, disorganization, and impractical management that puts the sneer into the term "HeroicProgramming." Sounds like what he has isn't HeroicProgramming but "merely" a high-functioning team. -- MarkSchumann
I wouldn't simply correlate HeroicProgramming with poor planning and disorganization, a.k.a doesn't work because it implies CowboyCoding. As CC, it's a risky approach, but most of us can probably feel the crawl in the back of the skull when it's time to ShutTheFuckUpAndWriteSomeCode?. I've seen HackerWorkshops? thrive in this kind of approach. It can be the answer to technical things we should be transparently just doing from the start (assuming it's a GacyBunch?). It might get product decisions all messed up, though. But I'd generally trust a (peer I know/work with and respect) hacker's decision any day. Functional business statistically get things all wrong a lot more.
NotEnoughTime, TooManyFeatures? and YouAintGonnaNeedIt don't necessarily correlate. I think that a genuine HeroicProgramming style can be generally considered a GoodThing.
-- LeoBighetti?
Here's an idea. I've got a 10000-line computer game that's unfinished and I'm partly loathed to go back to it, as I programmed it in straight C, the first 6000 lines went by without even using a single "struct" command! What I reckon would be useful is some sort of programming method that allows you to add new functionality to a program that was originally written really badly, without breaking it... I'm probably dreaming. I know there are various salvage operations you can do like putting all new code in separate functions to isolate it from the rest of the mess... [stephenbrooks@cs.com]
You're talking about ReFactoring--try searching on that term in the Wiki or in any of the several good books on ExtremeProgramming.
WorkingEffectivelyWithLegacyCode is a good book for this particular situation.
"more projects have failed through the insufficiency of HeroicProgramming than from any other single cause."
At first glance, you seem to be saying that "projects fail because programmers were insufficiently heroic". But now I understand that "projects fail because all the HeroicProgramming in the world would be insufficient to rescue them". In other words, "projects fail because too many people believe that HeroicProgramming is the SilverBullet". -- DavidCary
I personally have resolved to never again participate in any HeroicProgramming efforts, unless I want to do it for my own reasons. We currently have a project that cannot possibly be completed in the necessary time, but in spite of that, I am leaving at 7:00 PM every day. I felt guilty the first few days, seeing co-workers prepared to work long into the night, but I've concluded that it is not my fault if they are not doing the sensible thing. If I ever see that an 80-hour week really will help things along, I may change my stance, but for now, I'm going to just say "no".
I hope the rest of you will do the same. As long as the majority of programmers are willing to do stupid things to bail out their incompetent managers, we're all going to suffer.
As much as I agree, it's a delicate decision to make. I've seen this fall to JustStopCaring.
"I am leaving at 7:00 PM every day."
That still seems like a heavy workload to me. I get into the office at 9.30, and leave at 6.00. What ever happened to the old 9 - 5? The way I figure it, 37.5 hours of work in a week is enough for anybody. -- MarkCarter?
It would be interesting to hear people's opinions about WhyProjectsFail?. Here's a few off the top of my head:
* unrealistic expectations
* fundamentally-flawed ideas caused by lack of critical thinking
I'm sure that there are many many other reasons
Probably belongs on another page, though - there's a lot about failure already on the Wiki. Try a FindPage with "fail" ...
See classic humor piece at http://www.annoyances.org/exec/show/article09-209
As long as the majority of programmers are willing to do stupid things to bail out their incompetent managers, we're all going to suffer.
In my experience, the problem is not that HeroicProgramming exists, it's that a lot of programmers want to do it and that there is a company cultural assumption that people will do it. A lot of people like the idea of being the hero, and want to be thought of as the person who saved a project: we all want praise for doing a good job and pulling a project in on time. Managers love a HeroicProgrammer? because that programmer is papering over the cracks (or gaping chasms) in the project (at whatever level, be it technical or managerial). Companies who operate a meritocratic promotional system also often see the individuals as key to the success of a project (or failure), and are hence inherently geared to having low TruckNumbers?. These combined mean that the focus shifts towards individual effort and away from collaboration towards a common goal, hence a HeroCulture arises. No-one wants to be seen as the ScapeGoat or feel as though their perceived lack of effort was the cause of failure for the project. So everyone tries to work harder than the other guy, hoping they'll be the one who has the breakthrough and meets the deadline set by the project manager. It is the worst case of WeWillTry. Pity the person who "wins" and becomes the hero, because she's set a precedent for future and management will expect her to be the hero again when the next project strays too close to the rocks. Do this a couple of times, and you're well on your way to forming your own fully fledged HeroCulture.
Another issues is that often the ones regarded as heroes are those who stay long hours to fix things that were done wrong in the first place, as opposed to those who did it right in the first place, and went home on time every day. I worked at such a place, where the Employee of the Month award was given to the same guy 3 months running because he was staying late to fix code he bollixed up by coding without a design.
I've found that deciding DoNotBeTheHero? encourages concentration. When I know I'm leaving after eight hours, I really try to get something done during the regular work day. Mostly I succeed, and avoid the graduate student dormitory atmosphere so common in programming.
Arguably, a BadProgrammer pursuing this heroic path could very well be considered one of the worst ProgrammingNaturalDisasters? one could ever experience.
The CVS update on the following morning could not be safe for the faint-of-heart or, say, before the first sip of coffee.
-- LeoBighetti?
See also SprintToTheDeadline
EditText of this page
(last edited November 19, 2014)
or FindPage with title or text search