Slashdot Mirror
The Sad Graph of Software Death (tinyletter.com)
An anonymous reader writes: Programmers, raise your hand if you've been on a project where bugs keep piling up, management doesn't dedicate time to fix them, and the whole thing eventually bogs down. Gregory Brown summarizes that situation in one simple little graph from an issue tracker, and discusses why so many companies have problems with it. "This figure tells a story that is no way surprising to anyone who has worked on software projects before: demand for fixes and features is rapidly outpacing the supply of development time invested, and so the issue tracker is no longer serving as any sort of meaningful project planning tool. In all but the most well-funded, high functioning, and sustainable businesses — you can expect some degree of tension along these lines. The business side of the house may blame developers for not moving fast enough, while the developers blame the business for piling work on too quickly and not leaving time for cleanup, testing, and long-term investments. Typically, both sides have valid concerns, but they don't do an especially good job of communicating with one another." What methods have helped you deal with situations like this? What methods haven't helped?
You're skipping the part where the project was understaffed in the first place, requirements were ill-defined and ever-changing, and the final arbitrary, unrealistic, pie-in-the-sky delivery deadline date (the ONLY immutable thing in the whole goddam project) was pulled out of someone's ass. Oh. And the devs got pulled away on occasion to fix hair-on-fire bugs in projects they worked on previously (or even better: had no experience with).
Thanks for these headlines - reminds me of how good I got it. My manager is a former developer. I have, maybe, two or three hours of meetings a week. The issue list is planned out every Monday - if something high priority comes in, something gets taken off the list. If anyone starts monopolizing my time he fends them off or clears the schedule.
I have an acquaintance who went to work for a huge web company (not that one, the other one.) He's a pretty experienced developer, so he grilled them on their development process during the job interview. All the right things were said. They were all lies. He quit after two weeks.
My Other Computer Is A Data General Nova III.
I was handed a problem where SQL couldn't handle the parameters in code from a product that wrote code in a convoluted way. It took me two weeks to handle it, but the fix I eventually pushed out made sure that the issue would never happen again.
Despite the fix working for about ten years now, I never got an apology for being punished over the fix taking more than the nitwit manager saying it would take to fix.
If you want code teams to fix stuff right, make sure that the code guy is a manager. If you want someone to blow smoke up your ass and punish people that fix things promote suckup people that have no idea on how to code, or hire h1b's.
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
I can't say this is terribly helpful advice. The problem is that all companies are dysfunctional in some way. The problem as described is very common. As a professional software developer it might be a good idea to actually provide solid professional advice on proven ways of extraction from these nasty anti-patterns. We all live in a society where there are ignorant, selfish, mean and frankly stupid people around you every day. Your only real decision is how you will deal with it.
Will you cut and run the instant you are in a difficult situation that isn't perfect? How boring is that? I would rather join a company which is has dysfunction, has problems, but at least has people self aware enough to listen. I have found most managers are prepared to listen. You can join a company and provide the guidance to work better. Not right away of course, that would be rather arrogant, but once you find your feet and understand how it works you can provide advice and perspective. And even when there are areas that cannot change you would be surprised what you can achieve without formal permission.
Weekly meeting, meeting about meetings, meetings to assess the requirements for feature request, code reviewing others, triaging automated tests etc all happen first at my work. Add to that ~10 stat holidays and 15 vacation days: guess what doesn't happen on the weeks those happen? You guessed it coding. The emails still need to be answered, meetings get scheduled around your days off etc. So that 7 hrs out of the office comes right off the development time. Then you end up with a meeting about why features are coming slow :)
Management of at least feature bugs: the problem is prioritization. People use the bug trackers as a note pad to drop any idea for a feature they have, regardless of if a customer has actually asked for it, whether another bug for the same or a mutually exclusive feature already exists, whether the feature will actually raise demand or sell service contracts enough to justify the expense of development and ongoing support etc. Bug trackers become a pool of ideas that no one has bothered vetting.
My suggestion would be: management should be the only ones that can add bugs to the tracker and their compensation should be linked to how clean they keep it, something like: -$100 for every bug that doesn't get worked on in a year: either you aren't staffing properly, are loose with what you let in, aren't doing the necessary work to fill out the requirements enough so that devs can start working on it etc. All management failures. I'd be okay with that as a dev: if I can't explain why a technical feature or fix is necessary and what business impact it would have well enough that my manager prioritizes it then it shouldn't happen. If it not happening means the project fails well who denied the features resources ... managers. You know the guys the business has entrusted the project to?
To keep trackers clean I think everyone should keep their own separate list of ideas. The tracker should only have stuff that is currently being worked on or can reasonably be expected to make it in the next release. Have a meeting every few months and everyone can try to sell their ideas. A bunch get picked as the priorities for the next release and added to the tracker. Those that are no longer relevant don't even get seen by more than one person (or the guy with bad ideas quickly gets found out and shot). This has the added benefit of the devs participating and seeing the thinking behind the choice of features for a release rather than having it slowly revealed as the boss comes by and drops a new item that "must happen this week" on their desk.