Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Programming Software Technology

The Sad Graph of Software Death (tinyletter.com) 210

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?
This discussion has been archived. No new comments can be posted.

The Sad Graph of Software Death

Comments Filter:
  • Management (Score:5, Insightful)

    by Lisias ( 447563 ) on Saturday January 02, 2016 @09:22PM (#51228715) Homepage Journal

    Communication is the main task (and, IMHO, should be the sole one) of managers.

    Get rid of that wave of mongols that call themselves "Managers", give the task to someone that can understand both sides, and you will see things going better.

    • Re:Management (Score:5, Insightful)

      by Anonymous Coward on Saturday January 02, 2016 @09:58PM (#51228805)

      My problem is this one

      'drop whatever you are doing this is your top priority' then 'why is xyz not done yet'.

      I spend at least 2-3 days a week in meetings. The remaining time is spent doing 'support'. The other time is supposed to be my development time. Guess which one suffers?

      My 'passion' is gone. I come in at 9ish leave at 5. I then take a decent lunch. I dont care anymore. They do not want to let me schedule time for dev work. I am not going to give them extra time. They dont care then I dont.

      • Re:Management (Score:5, Insightful)

        by Anonymous Coward on Saturday January 02, 2016 @10:43PM (#51228949)

        I have thought about having T-shirts printed up that say "The meetings will end when morale improves". There is nothing like an excessive number of meetings that sucks the life out of me. Fortunately I don't work on that product any more.

        • Re: (Score:3, Funny)

          by Anonymous Coward

          “If you had to identify, in one word, the reason the human race has not achieved, and never will achieve, its full potential, that word would be ‘meetings.’ ”

          -- Attributed to Dave Barry

          Unfortunately, many modern development practices call for increased numbers of meeting.

      • by ILongForDarkness ( 1134931 ) on Sunday January 03, 2016 @08:28AM (#51229935)

        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.

        • by Z00L00K ( 682162 ) on Sunday January 03, 2016 @12:45PM (#51230539) Homepage

          If management were to add bugs into the bug tracker then you would have complete chaos - most managers don't know crap about what the bug reports are about and can't distinguish a bug from an enhancement. Let it be the responsibility of the developer to re-classify bugs that should be enhancements and submit such to a decision board for future enhancements.

          • Oh agreed. Devs have to be the ones that say something is a bug or a new feature (often they mingle, either bad requirements (or don't know the requirements yet because trying something new)). Really it is all a matter of accounting though. There might be bugs in the product that aren't significant/no one cares so fixing them would be a waste. The guys responsible for the business still have to decide what level of quality they want vs new features. Devs generally speaking will keep working on something til

            • by Z00L00K ( 682162 )

              Also realize that sometimes a small bug can get fixed if you are in the area of the code where you do some other change like correcting a major bug so just saying that "we don't fix that bug" or killing the small bug issue with a "won't be fixed" statement is essentially stupid.

              • Good point. This is the challenge of managing a task list. You don't want to forget about things but at the same time feel guilty when things pile up past the point you have any reasonable expectation of "getting done". I like having an empty email box, personal task list. I think that carries over to work but maybe shouldn't. After all if you run out of things to do that means your out of a job, or at least your product is "done"/dead.

                Fixing minor bugs "while I'm at it" is a constant battle of mine. I agre

      • by Z00L00K ( 682162 )

        If you spend 2-3 days in meetings then that's the primary problem. 90% of all meetings are not productive at all, and that's especially when it comes to information meetings.

        If you have more than 4 hours of meetings per week on average then you are wasting valuable time on meetings. In most cases you can actually decline a meeting call without ill effects. Another trick is to schedule work time as meetings so that in your calendar you look busy with other meetings when people try to book you into a meeting.

        • If you have more than 4 hours of meetings per week on average then you are wasting valuable time on meetings. In most cases you can actually decline a meeting call without ill effects. Another trick is to schedule work time as meetings so that in your calendar you look busy with other meetings when people try to book you into a meeting.

          Wisdom. I've used the 2nd trick for awhile, just started using the first one (unless boss says that I must be there). Boss is not the type to hold useless meetings, thank goodness. I've had bosses who were constant droning talking heads at constant meetings. I apply the appropriate part of my brain for those: the stem.

    • Re:Management (Score:5, Insightful)

      by sunderland56 ( 621843 ) on Saturday January 02, 2016 @10:13PM (#51228841)

      No, I think that being an effective *filter* is the main task of a manager. Communicate and prioritize the requirements from above that make sense; but block ones that are stupid or not worth it. Communicate the needs of the team up to management (again, ones that make sense) and make sure they get addressed. And, most of all, block the constant stream of questions and requests from sales/marketing/support, and force them to all pass through you. That way you (a) will soon recognize who brings reasonable requests, and who does not; (b) get to know which areas of the product get the most questions, and so may need work; and (c) allow your team to work mostly uninterrupted.

      You're right that under-communication is an evil sin; but so is over-communication.

      • by Lisias ( 447563 )

        No, I think that being an effective *filter* is the main task of a manager. Communicate and prioritize the requirements from above that make sense; but block ones that are stupid or not worth it

        As soon as the manager starts to filter information, it starts to take decisions indirectly about the project. If the guy knows the matter, it does it right. However, if the guy knows enough to know what to filter, the guy should not be being wasted on communications - the guy should be in a active hole on development.

        Managers should manage. And nothing more.

        Communicate the needs of the team up to management (again, ones that make sense) and make sure they get addressed. And, most of all, block the constant stream of questions and requests from sales/marketing/support, and force them to all pass through you. That way you (a) will soon recognize who brings reasonable requests, and who does not; (b) get to know which areas of the product get the most questions, and so may need work; and (c) allow your team to work mostly uninterrupted.

        You're right that under-communication is an evil sin; but so is over-communication.

        So in the bottom like, I got it right from the start. I said that Managers should communicate. :-)

        And there's no such thing as "over-communication". Wh

        • by tlhIngan ( 30335 )

          As soon as the manager starts to filter information, it starts to take decisions indirectly about the project. If the guy knows the matter, it does it right. However, if the guy knows enough to know what to filter, the guy should not be being wasted on communications - the guy should be in a active hole on development.

          Managers should manage. And nothing more.

          A manager manages by filtering information. Customers, sales people, etc., request features, the manager consolidates these requests down, sees what ma

          • by Hylandr ( 813770 )

            >Depends - if you're the only developer doing this because you're the one who knows most about the project, congratulations - you got promoted to manager, or at least now manage your team. Because you're being pulled into meetings means management thinks you've got stuff to contribute. If everyone on your team is like this though, then the development process is screwed, and you need to have a strong word with your manager to tell your team to cut back on time sinks..

            >If you're the only one there beca

    • Communication is the main task (and, IMHO, should be the sole one) of managers.

      You mean except for budgeting, staffing, scheduling, conflict resolution, planning, reporting, coaching, motivating, forecasting, negotiating, delegating, and the thousand other things a manager actually has to do in the real world?

      If you think communication is the only thing a manager should have to do you are pretty clueless about what it takes to manage a group of people. Effective management is a hell of a lot more than just "communication".

      • by Lisias ( 447563 )

        You mean except for budgeting, staffing, scheduling, conflict resolution, planning, reporting, coaching, motivating, forecasting, negotiating, delegating, and the thousand other things a manager actually has to do in the real world?

        No. I mean exactly what I said.

        Budgeting, staffing, scheduling, planning, coaching, negotiating and a lot more must be done by people that knows exactly the consequences of their decisions. If the guy that does this all effectively has the skills to do that correctly, the guy's skills shouldn't be being wasted on non productive tasks. This guy should be doing active development!

        If you think communication is the only thing a manager should have to do you are pretty clueless about what it takes to manage a group of people. Effective management is a hell of a lot more than just "communication".

        If you think that MANAGEMENT should do anything else, you are delusional or you make money convincing people otherwise. :-)

        Managers should MANAGE. Nothing more.

        Managers don't take decisions. Managers manage the decision taking.

        Managers don't do budgeting. Managers manage the budgeting process.

        Managers don't plan. Managers manage the planning process.

        Managers don't solve conflicts. Managers manage the conflict solving process.

        And so on.

        Reporting, coaching, etc are COMMUNICATION tasks - where Managers should excel.

        • by Lisias ( 447563 )

          what the hell is going on with this site? Sometimes I can't login! Others, post me as anonymous coward besides being logged!!!

      • by Lisias ( 447563 )

        (sigh) Let's try again.

        Communication is the main task (and, IMHO, should be the sole one) of managers.

        No. I mean exactly what I said.

        Budgeting, staffing, scheduling, planning, negotiating and a lot more must be done by people that knows exactly the consequences of their decisions. If the guy that does this all effectively has the skills to do that correctly, the guy's skills shouldn't be being wasted on non productive tasks. This guy should be doing active development!

        You mean except for budgeting, staffing, scheduling, conflict resolution, planning, reporting, coaching, motivating, forecasting, negotiating, delegating, and the thousand other things a manager actually has to do in the real world?

        If you think communication is the only thing a manager should have to do you are pretty clueless about what it takes to manage a group of people. Effective management is a hell of a lot more than just "communication".

        If you think that MANAGEMENT should do anything else, you are delusional or you make money convincing people otherwis

  • Welcome to the world, where bugs are just part and parcel of life.

  • The graph in TFA shows that half of the maintenance team was removed on March 7th. Both new issues and retired issues are going linearly with time.
    • half of the maintenance team was removed on March 7th

      The graph starts on March 15th.

      I think April 15th just shows where they lost their enthusiasm.

    • Re:Obvious, really (Score:5, Interesting)

      by NoNonAlphaCharsHere ( 2201864 ) on Saturday January 02, 2016 @09:51PM (#51228789)
      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).
  • I like to think of technical debt in the ratio A:B ... A is always 1, perfect. B is what you achieve. So a ratio of 1:2 might not be that bad for a core enterprise system. 1:50 could be fine for a quick and dirty proof of concept. When designing a new system, module, or major upgrade...a frank discussion is needed with the requisitioner on what A:B ratio is being aimed for. Model it out, with risks, attaching notional monetary values to the cost of poor quality. Then...your job is done, the informed choic
  • Idiots (Score:5, Insightful)

    by penguinoid ( 724646 ) on Saturday January 02, 2016 @09:35PM (#51228747) Homepage Journal

    The business side of the house may blame developers for not moving fast enough,

    Yes, but that is the most pathetic excuse ever. No one is preventing the business from hiring additional workers, if the business lied about its workers' capabilities or is managed by idiots who substitute optimism for basic estimation skills that's their own problem.

    • Re: (Score:3, Insightful)

      by Ichijo ( 607641 )
      But according to Brooks' law [wikipedia.org], adding manpower to a late software project makes it later. So hiring additional workers would actually be counterproductive.
      • by m00sh ( 2538182 )

        But according to Brooks' law [wikipedia.org], adding manpower to a late software project makes it later. So hiring additional workers would actually be counterproductive.

        Different situations. Brook's law is for when there is a deadline for a software to be delivered.

        In this case, there isn't a deadline. It is a continuously supported product.

        It would take at least 6 months for the new developers to get up to full speed.

        However, I would think hiring additional workers would make the "problem" worse. With additional workers, there is more rapid feature development leading to more fix and feature requests.

        • > In this case, there isn't a deadline. It is a continuously supported product.

          There are release dates, feature releases, and bug fix delivery dates. Those are also "deadlines".

          • It stands to reason that if adding people to a project makes it later then taking them away makes it earlier.

            That's why I is a manijer and you isn't.

          • > In this case, there isn't a deadline. It is a continuously supported product.

            There are release dates, feature releases, and bug fix delivery dates. Those are also "deadlines".

            Yes, hiring more men will not make fixing the bugs and features already being worked on any faster, but it can mean they can work on bugs that aren't being worked on, and which could lower the work-load or stress from the existing developers when they are done with their current projects.

            Hiring extra man-power works as long as there are extra tasks that aren't being worked on.

      • by khallow ( 566160 )

        But according to Brooks' law, adding manpower to a late software project makes it later.

        If one wants to see what happens when someone uncritically applies a witty aphorism without regard for reality, see Hognoxious's reply [slashdot.org]. The second obvious rebuttal to your post is that you didn't read the fine print [wikipedia.org].

        According to Brooks himself, the law is an "outrageous oversimplification",[1] but it captures the general rule. Brooks points to the main factors that explain why it works this way:

        It takes some time for the people added to a project to become productive. Brooks calls this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.

        Communication overheads increase as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.[3] Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.

        Limited divisibility of tasks. Adding more people to a highly divisible task such as reaping a field by hand decreases the overall task duration (up to the point where additional workers get in each others way). Some tasks are less divisible; Brooks points out that while it takes one woman nine months to make one baby, "nine women can't make a baby in one month".

        Three obvious points here are that first, this being a continuous operation rather than a one-time deadline, training competent software developers always works out in the long run even if short term deadlines are missed. Second, a big part of the workload here, bug fixing is for the most part,

  • by Shadow of Eternity ( 795165 ) on Saturday January 02, 2016 @09:36PM (#51228751)

    ...is the spoon a failure? Or are you just a fucking imbecile?

    Technology is not magic. The problem here is caused almost wholly by people who do not understand, and actively refuse to understand, the technology they are working with. So they wind up being completely unreasonable in the long run and then blaming coders when things go south. It's like someone buying a cheap sedan and expecting it to go a million miles non-stop without any service or maintenance while driving it like it's a rally car. The car's just fine, the driver has unrealistic expectations.

  • The Sad Graph of Software Death

    Right. Here's one of my big gripes with Slashdot. Months ago, you brought in video. But you still don't have articles with images, even when they are the main point of a summary? That's pretty lame.

    • Re: (Score:2, Offtopic)

      Here [youtube.com] you go.
    • You say articles, but these are not articles. You are confusing a news aggregator with a corporate property intended to make a profit.

      That's why I block everything but text. And if all text loads via JavaScript, I'll move on to the rest of my bookmarks, minus dashslot.

      Click or do not click, there is no whinge

  • by Jeremi ( 14640 ) on Saturday January 02, 2016 @09:54PM (#51228799) Homepage

    ... is, if you're still receiving bug reports and feature requests, that means people are still interested in using your software.

    You know a particular program is really dead when you stop receiving feedback from users about it -- that means either it is finally perfect and bug-free (ha ha, not bloody likely), or everybody has given up on it and moved on to something else.

    • by Z00L00K ( 682162 )

      Tell people that call you to meetings to bugger off. If they insist, have them explain WHY you shall be on that meeting. If they can't give a good explanation just say to them that you have a more important meeting going on at that time. If they still insist that you shall be on their meeting and still can't explain why you shall be there then they are just there to mess up things with their meeting.

      The importance of a meeting is inversely proportional to the number of participants. It's usually in the smal

  • by mikael ( 484 ) on Saturday January 02, 2016 @10:19PM (#51228867)

    Figure out what those bugs are coming from. Are they documentation, failed unit tests, new features, badly colored GUI widgets, or more hardware features?
    It isn't going to help to have a recruitment blitz for more hardware engineers if your technical writers can't keep up with the documentation.

    • Analysis is indeed the first step; you need to know what's broken if you are to fix it. Take a few days to take inventory of the issues. Is this indeed a mess of duplicates, resolved issues left open, and non-issues? Then you can remove those and set about fixing the bug registration and tracking process.

      If these are real tickets though, then this is what I would suggest in the case as presented by the author of that article:
      Start with a broad categorisation of open issues. Which issues are bugs, wh
  • 1. Fire all managers.
    2. With the money this frees up, triple the programmer headcount.
    3. Profit.

    • 4. With all the bugs fixed, you can now fire the programmers.
      5. Rehire the managers.
      6. Repeat!

  • Be professional (Score:4, Informative)

    by phantomfive ( 622387 ) on Saturday January 02, 2016 @10:21PM (#51228881) Journal
    These are [amazon.com] my two favorite books [amazon.com] for dealing with the problem.

    Clean Coder is the latest Uncle Bob book, and IMO his best. It shows how to act in a way that managers don't make weird demands of you, and how to handle them when they do. Essentially it boils down to this: be professional.
    Zero Bugs teaches how to reduce the bug count when you write it, so you don't get overwhelmed as you go along.

    Generally I've found managers/customers understand that features take time, and they are happy as long as you are reasonably close in your estimates. But when your product is buggy, and you miss your delivery dates by months, that's when they start getting upset.
    • I was interested in reading "zero bugs", but it doesn't come in ebook format. Who releases a book in paper only format in 2015... especially a programming book?

      Anyhow, if your organization is dysfunctional enough to let things degrade into a holy hell of a mess in the first place: don't request "bugfixing time" or "code reorganization time", as it will probably never happen. Bugs are just incomplete or broken features. They don't exist in isolation. Reduce the rate of new features until you've fixed the

      • Reduce the rate of new features until you've fixed the old ones. When you're in a pit, you need to first stop digging. In this case, its probably better to ask for forgiveness than for permission. I'm not suggesting you lie by any means, but don't treat bugs like they exist in isolation from the rest of the features you were working on. It's a huge mistake to slap out a half-finished feature and then move on without fixing all the little issues that crop up as a result of that feature.

        A lot of the programmers don't know how to actually do this. They don't know how to keep bugs out, even with ~infinite time, because every time they change the code, they add bugs.
        It's a people problem: you need to start by making your programmers better programmers.

        In my own code, I'll occasionally run into "smells"... things which seemed reasonable enough or perhaps simply expedient at the time, but later started bugging me whenever I looked at the code or thought about how its organized. Every so often, between new features, I'll dig deep and clean up one of those "smells", which often has no tangible benefit other than making the code cleaner and safer.

        This paragraph tells me that you don't have that problem; you're the kind of programmer I would like to have as a coworker. No one writes perfect code the first time, but good programmers are the ones who think about how to avoid bugs and impr

  • by Hairy1 ( 180056 ) on Saturday January 02, 2016 @10:23PM (#51228885) Homepage

    This is of course a well known problem documented in the paper Big Ball of Mud by Brian Foote:http://www.laputan.org/mud/. The basic problem is that many systems grow organically as new features are required, but as new features are added to the system it becomes more complex and tightly coupled. Another aspect I have noticed might be the 'Black Hole' syndrome. In systems that are custom written and business critical there is no clear scope of the project. With no clear scope anything new that the business needs is simply thrown into the existing system. The never ending scope creep means that the system takes more and more responsibility. And so grows a monolithic tightly coupled black hole. Because it is at the centre it tends to attract any new requirements because anything new needs to interact with it. And the more you add the harder it is and the more bugs you introduce.

    There are well known solutions of course. The first would be to read the link above. However, there are two broad areas to address, and you need business buy in for both. The first is software development discipline; proper code repositories, regular check in, unit tests, code reviews. And while there should be nothing new here there is often resistance from management. You need to explain to management that poor quality means lower development velocity. Taking time to do testing and code reviews may appear to take time, but try not doing it and you find out pretty quickly the folly of ignoring quality. This is just basic coding hygiene. You can of course also apply agile principles and practises, such as time boxing of iterations and regular feedback from users.

    But okay, you have an existing system you need to fix. Service Oriented Architecture is more than just a buzzword; it is the principle of separation of concerns. First thing to do is define what the system does. Does it do multiple things? You need to have a clear idea about what the system does, and to then begin to cleave them into separate systems with clearly defines scopes. Sometimes this means identifying relatively simple subsystems to separate. Break the system apart and introduce well defined contracts.

    Refactoring code without getting a eagles eye view of the whole system and where to introduce the interfaces is dangerous. Often this process of architectural clarification can cause systems to experience complexity collapse as duplicate code is reduced and removed. Premature re-factoring at the class level may introduce little benefit. Better to pull off the small subsystems with a clear scope and purpose and ensure the code in these new subsystems do not include unnecessary external domain objects.

    Again, without having the business behind you a project like this is doomed. You need to present a clear plan to the business and explain how it will improve quality and the ability to add new features, while reducing development costs. You need to explain that this is not a issue with the quality of software developers, but rather a systemic problem that can be corrected. And of course for this you need someone with the courage to tell this story in a compelling way.

    • That's all BS.

      The problem is: If you find yourself in this situation, your manager is used to crapping on the floor. Just like dogs, poorly housetrained managers are much more of a problem than fresh managers. Worse still, many employers actively discourage hitting your manager with rolled up newspapers. Quit your job if it's the only way to find new managers. It's true that more are bad than good, but with experience you will learn to recognize the stink during interviews/office visits.

      Don't be afraid

      • Re:Bingo! (Score:4, Interesting)

        by Hairy1 ( 180056 ) on Sunday January 03, 2016 @01:22AM (#51229281) Homepage

        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.

    • > The basic problem is that many systems grow organically as new features are required, but as new features are added to the system it becomes more complex and tightly coupled

      Your whole message makes much more system of you spell "systemd" instead of "systems". I'm sure that was a typo.

      • Oh, that would have been much funnier if I'd said:

        > Your whole message makes much more sense if you spell "systemd" instead of "systems". I'm sure that was a typo.

        I do apologize for doing that joke so poorly. I'll try to avoid humor in this forum.

        • No worries. As a wise man writing a different article summary today, "This is might sound wonders".

  • Developers how have not figured out new ways of solving old problems. They dogmatically hit the wall in the same way over and over again. It's worse when developers with lots of experience get promoted into management and stay there because they can charm they way there. If they realize that it's a different type of job and start managing people (keep egos in check, deescalate tensions, etc.) while researching new ways of solving old problems and let people develop, they build people up. If they just tr
  • Most software is not fine art, it's a tool made by paid professionals for paid professionals. If there isn't a viable return on the investment made for maintenance and enhancement, the program will languish and die. Programs are not people a right to live and be cared for. Often the business decisions are faulty and software that is worthy of investment is ignored. These businesses are often not competitive and they die along with their creations. Sometimes a program's value only warrants a minimal maintena
  • Like the article said, this could well be a symptom of poor or clueless project management. Duplicate issue reports and low-priority nice-to-have items may be overwhelming actual problems. On the other hand, this could also be a case of software "maturity" where it becomes difficult, if not impossible, to fix any bugs without introducing new ones.

    The least bad "solution", as a technical lead or developer, is to abandon the problem tracking system. To politically sell this idea it describe it as a "critical bug tracking system" and make it a simple command-line or email interface that only the lowly code grunts and technical leads will be comfortable with.

    Another "solution" is to start closing problems and declaring they cannot be fixed without a redesign of the product.

    One thing to remember is that substituting product management with a bug tracking system is seriously lame. We all use software, from web browsers to compilers to editors to source control systems to databases, that has bugs. Each new release of said software will fix some bugs and introduce new ones. Most of the time, for most users, if we had a choice between fixing those bugs and making the product in question ten times as fast or use 10% the memory we'd take one of the latter over the bug fixes. What I'm trying to communicate is that an "issue tracking" system can't usually communicate what customers want or need perfectly.

  • by SuperKendall ( 25149 ) on Saturday January 02, 2016 @11:30PM (#51229061)

    I think a lot of the problems software development has, could be solved by ending the absurd game of telephone we are all playing as to what the people using the software are actually wanting.

    It's easy in a bug fix swamp to lose sight to lose track of what the hell working even means, or what is important to HAVE working.

    It's impossible to avoid creating massive technical debt without understanding the possible futures for what you are working on, futures that sorry to say non-technical people are awful at interpolating from the user desires and issues of the day.

    In so many companies I've worked at, developers are given at most the tiniest bits of information or contact with real users or customers. If you ever want software to really improve, that must end. Heck, most companies should probably have programmers shadow a real user for at least a day at least once a month.

    I think companies are loathe to do this because of the myth that software developers are anti-social - in reality I don't think it's any more true than any other group of people (except of course for sales people). And on a side note if someone is difficult for a customer to get along with, why on earth do you think they would be good for team dynamics....

    • > ending the absurd game of telephone we are all playing as to what the people using the software are actually wanting

      Please, yes. Whenever I count too many layers between the clients who pay for a service, and the engineers who write it I become deeply concerned that they can and will confuse things at any intervening step. When possible, I try to get the engineers to spend at least some time every week manning the help desk. It doesn't have to be consistent, and ideally it's not so that customers don't

    • I agree with this.

      There is on one hand architecture, and on the other usability. The end users shouldn't directly be involved with the architecture, but since they are going to use the thing, they should have a whole lot to say about how it should work. Not some guy who makes up some arbitrary user stories based on a few talks with end users (but those can be a base to start with).

      In the (internal) project I'm working on, at first we had a non-programmer collect requests from the end users. He would come ba

    • I don't think it's people skills exactly, it's something more like this [dilbert.com] and this [dilbert.com].

      Not that extreme usually, but often programmers spend their time nitpicking over things that don't matter (at least, that don't matter from the salespeople's perspective).
  • by Anonymous Coward

    On a couple of occasions, there have been attempts to completely sidetrack us onto some other highly urgent project for a product that is not what we normally work on. This ignored several relevant points.

    1) We are primarily C/C++ programmers. These other products were primarily Java based.
    2) We knew nothing about the internal architecture of these Java-based applications.
    3) We are not co-located with the developers who work on these Java applications. Questions would have to be posed by phone/email/skyp

  • Management (Score:4, Informative)

    by darkain ( 749283 ) on Saturday January 02, 2016 @11:47PM (#51229101) Homepage

    Whenever the question of management arises for programmers, I always return to the same manual. This single document is answers many of the questions regarding failure of IT projects in general.

    http://www.computerworld.com/a... [computerworld.com]

  • Got it good (Score:5, Interesting)

    by JBMcB ( 73720 ) on Saturday January 02, 2016 @11:55PM (#51229115)

    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.

  • by dcollins ( 135727 ) on Sunday January 03, 2016 @01:00AM (#51229223) Homepage

    Looking at the graph in the article, there's on obvious inflection point that occurs on 7-Apr. Prior to that, the two lines (opened and closed items) are basically tracking each other. After that point, the opened items (red) retains the same slope; but the closed items (green) switches to a different, shallower (but thereafter basically constant) slope. And thus the two curves veer away from each other from that point.

    So: What happened on 7-Apr? Did one or more developers quit, burnout, take a long vacation? Maybe they haven't been replaced yet?

    After that I'd try real hard to stop new features from coming in, and start thumbing through a Brooks book to look for suggestions in an emergency like this.

  • by the_Bionic_lemming ( 446569 ) on Sunday January 03, 2016 @01:13AM (#51229261)

    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.

    • Actually, after sitting and thinking about this - managers have two modes.

      1. Did you fix it and help the company, and make me look good?

      2. Did you fix it and help the company, and make me look bad?

      The fix is the fix. Stop blaming me.

  • That graph might be perfectly ok. All it shows is bugs outpacing fixes. But if the product has been expanded with more feature areas, each bringing more minor bugs but also a higher product surface area.

    The best thing to do is probably to go down the list and close off the ones that won't be fixed. We know it's a bug but it's low impact and not worth fixing - at least be honest about it.

    • "But the customer is always right!"

      "We cannot tell the customer we will not fix!"

      Blergh....
      Public issue trackers tend to bring a lot of corporate politics into the process of trying to efficiently use the tracker for what it is meant for. Sigh.

  • The graph of software death looks much worse than this. What we see in this graph is that the number of open issues in this project grows linearly with the number of issues resolved. This is normal; the number of open issues directly corresponds to the size/complexity of the software. Many issues are likely not ever going to be resolved and in practice this is fine; for most software the economically optimum quality level is simply not "issue free".

    Also, it is highly likely for software to gain features that are not going to stay. The bug count for such features will grow and make your graph look very sad. However, once the component is dropped and all open bugs can be closed, you will often see that a relatively large number of bugs were in that component. Without such information, it is impossible to tell what a graph is trying to tell you.

    The sad graph of software death does not just have the number of open bugs growing; that's normal. It has the created:resolved rate itself growing. This might, however, be very subtle; perhaps even this projects' bug count is growing exponentially, but with a mere 15 data points it is impossible to tell.

    So if your project looks like this graph, which I'm pretty sure it will if you're dealing with somewhat mature software that is continuously being developed, be happy about. You're just fine. Your software is not about to explode anytime soon. If, however, you see the created:resolved rate itself growing then you're in trouble.

  • Shouldn't the red line plateau at some point? It's not like a finite piece of software can contain an infinite amount of bugs.

    • Feature requests can grow infinitely, as can the number of duplicates of existing bugs. Unless you're diligently closing/merging duplicates and triaging feature requests, you're never going to plateau.
    • by mikael ( 484 )

      They should. The bugs should get more minor and less severe, and more obscure. Sometimes you have hardware designed using software simulators, FPGA's, prototype boards, final product unit, documentation. Then you write your software against all those development platforms, test it and update the documentation as you go along. There's a time where everything peaks. When the major bugs are removed, everything starts gliding downwards as duplicates are removed and fixing one memory fault bug coincides when oth

    • It will plateau when the software is obsolete and on the decline.

  • I worked for a company with PHBs above me as far as the eye could see. The word came down to reduce the bug count. Incentives were tied to the bug count coming down. The good news is that bugs were closed. The bad news is that many of those bugs were not fixed. So, yay, goal achieved, I guess, but now we didn't know what was broken, in many cases.

    I left without waiting to find out whether there was a perceived drop in quality, with more incentives for filing bug reports, (many of which were closed but not f

  • There's a simple solution to a growing quantity of open bugs: just hire someone to close them. There's plenty of ways to close bugs:

    • Find excuses to mark them WONTFIX (like: "this is a criticism of a design decision, not an actual bug report", you know: not-a-bug-its-a-feature)
    • mark a bunch of them as dupes (if need be you could open one general "Something's Wrong" bug, and mark all of them as dupes of it)
    • start deleting features at random, then you can zap any associated

People who go to conferences are the ones who shouldn't.

Working...