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?
Management (Score:5, Insightful)
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)
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)
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)
“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.
agreed dev time is the last to get allocated (Score:4, Interesting)
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.
Re:agreed dev time is the last to get allocated (Score:4, Insightful)
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.
Re: (Score:3)
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
Re: (Score:3)
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.
Re: (Score:3)
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
Re: (Score:3)
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.
Re: (Score:2)
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)
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.
Re: (Score:2)
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
Re: (Score:2)
A manager manages by filtering information. Customers, sales people, etc., request features, the manager consolidates these requests down, sees what ma
Re: (Score:2)
>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
Re: (Score:2)
For me, filtering the information is just a way to :
1) allow the team to work without interruption
2) obtain a clear description of the goal
3) distribute the work in function of the availability of people. If project could ask directly to the devs, it will be always the same guy who works.
If you agree that the word "proxying" can be used instead of "filtering", I can agree with you. It appears that we disagree only on the choose of words. :)
What management does (Score:2)
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".
Re: (Score:2)
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.
Re: (Score:2)
what the hell is going on with this site? Sometimes I can't login! Others, post me as anonymous coward besides being logged!!!
Re: (Score:2)
(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
Re: (Score:2)
Your list suggests that you aren't doing enough delegating, even if you're at a small company.
Alternatively, it suggests the he works on a third world company - where managers lives the illusion that they are the main and most important hole on development, being the developer's themselves just tools being used by the "master".
Re:Management (Score:5, Insightful)
I think that's not what he meant. What he meant is the management equivalent of the sales person who claims that it doesn't matter whether he's supposed to sell mattresses, cars or refrigerators.
A manager has to know at the very least (AT LEAST!) the pitfalls of what he is managing. Of course not the technical side, but the management side. In IT this means that he has to know that bugs WILL happen and that he WILL have to dedicate time to fixing them, that wishing them away will not work and that customers will want them fixed because they notice them and you can only bullshit them so long into "it's a problem on your end".
Re: (Score:3)
At several of my clients (not software development companies, but companies using a lot of bespoke software) I have noticed that often little or no money is being allocated to fixing bugs after the project completes. Not sure whose fault this is. The devs are hired hands who don't care about maintenance; they disappear after the project is completed. The sales manager of the company building the software doesn't want to rock the boat, neither does the business analy
Re: (Score:2)
A variation of "It's always easier to ask for forgiveness than permission."
Re: (Score:3)
Unfortunately, puritanical countries such as the US - which has the UK's classist legacy, compounded over the last 35 years by the neoliberal disease - views management as "wealth creators" and workers as "in their place". This has coincided with the decline of US economic supremacy.
If you think "puritans" are classicists, try to get a job on Portuguese colonized country.
Seriously, "doing work" here is demerit. The ones that get promoted are the ones that avoid working themselves.
Re: (Score:2)
Management are non-productive cost overhead,
workers are profit positive real wealth creators,
comrade !
Re:Management (Score:5, Informative)
Harshly put, and only partly right. Project managers manage resources, budgets, costs, stakeholders, timescales and as a result, the project.
The architect also manages the project, but takes accountability for the technical correctness of it, the design, the quality.
In other words, the answer is to get a good architect. Make them accountable for quality. Give them the authority to deliver on that accountability.
At this point the number of bugs becomes irrelevant, the complex compromises between functionality, security, user experience, data integrity, resilience, stability, availability and cost can be properly assessed.
Bugs are a tiny part of the whole.
Re: (Score:2)
On the other hand, where my son works, they laid off a lot of managers, and split their responsibilities among remaining management and those actually working on the projects.
Welcome (Score:2)
Welcome to the world, where bugs are just part and parcel of life.
Obvious, really (Score:2)
Re: (Score:2)
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)
Be honest about technical debt (Score:2)
Idiots (Score:5, Insightful)
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)
Re: (Score:3)
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.
Re: (Score:2)
> 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".
Get back to work! (Score:2)
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.
Re: (Score:2)
> 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.
Re: (Score:2)
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,
If you try to cut bread with a spoon... (Score:3)
...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.
Still no images, Slashdot? (Score:2)
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)
Re: (Score:2)
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
The other side of the coin (Score:5, Insightful)
... 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.
Third rule in a crisis situation.... (Score:2)
DUCK
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
I guess nobody but me remembers that movie.. yeah, it was horrible
Start by categorising bugs (Score:5, Insightful)
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.
Re: (Score:3)
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
There's an easy way to fix that (Score:2)
1. Fire all managers.
2. With the money this frees up, triple the programmer headcount.
3. Profit.
Re: (Score:3)
4. With all the bugs fixed, you can now fire the programmers.
5. Rehire the managers.
6. Repeat!
Re: (Score:2)
No, arsonists are productive, management overhead is like pouring cold tar into a machinery.
Re: (Score:2)
Unless, of course, they are intelligent people and say no to your request that they burn their lives up for you.
No amount of money can give you back the life you've missed.
Re: (Score:2)
Well, then at least you have the additional money and nobody who keeps your programmers from working.
Any way it turns out, it's profit.
Be professional (Score:4, Informative)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Well known problem; well known solution (Score:5, Informative)
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.
Bingo! (Score:3)
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)
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.
Re: (Score:2)
> 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.
Re: (Score:3)
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.
Re: (Score:2)
No worries. As a wise man writing a different article summary today, "This is might sound wonders".
orthodoxy (Score:2)
Its usually a business decision (Score:2)
at least partly a project management problem (Score:4, Insightful)
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.
Give us direct access to users (Score:3, Insightful)
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....
Re: (Score:2)
> 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
Re: (Score:2)
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
Re: (Score:2)
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).
Re: (Score:2, Insightful)
I hope you realize "direct access" does not necessarily mean "personal access." I imagine the poster was referring to the possibility to actually directly communicate with the people who will use the software, not try to divine it through several layers of managers and systems analysts. The ability to actually speak with a customer, ask them questions, and answer any questions they have for you might well work wonders in terms of producing the software that is actually desired, not the software that has b
Re: (Score:2)
I've been working for over two decades now - both in IT and for a long time now consulting for clients of varying sizes.
The large range of companies I've worked in and with have given me the general understanding of what is flawed between almost all companies...
I can understand you may not have had a similar breath of experience to understand what I'm talking about - Direct access to customers does not mean they have direct access back. It means software developers choosing how and when it makes sense to s
Developers as cogs in the machine. (Score:2, Insightful)
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)
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)
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.
Figure Out What Happened on April 7th (Score:4, Insightful)
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.
Here's what should happen but doesn't (Score:4, Interesting)
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.
Re: (Score:2)
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.
Context (Score:2)
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.
Re: (Score:2)
"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.
This is not the sad graph of software death (Score:3)
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.
Infinite bugs? (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
It will plateau when the software is obsolete and on the decline.
The lesser evil (Score:2)
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
when you've got too many bugs... (Score:2)
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:
Re: (Score:2)
Then why post, for fuck's sake? Brooks wrote a lot of words, and either it is familiar, or not.
I have mid points, but calling you out on something either redundant or not informative is much more help than moderating it as such.
Try to be helpful.
Re: (Score:2)
Woof. One thing that's needed on the entertubz is a thick skin, huh?
Re: (Score:2)
...when all that had to be replaced to increase productivity is the PHB.
Re: (Score:2)
design work is very difficult to get right though. software basically becomes the business paperwork process. So which parts get automated, which parts need manual adjustment, which parts the users see, and which parts they don't know about is sometimes very hard to figure out and 30 years later we are just starting to sort through it to do it right.
I took over some roles of the our previous finance guy. just basic reporting, information updating etc. Every month he had to manually calculate out specifi
Re: (Score:2)
I had a point to all this but my tablet submitted it before I finished. damn android.
managers, salespeople, etc may not exactly know what they want the software to do. software is only getting to the point where it makes sense for people. Knowing what the software can do, what you need it to do, and how it does it is very difficult.
My personal favorite example is a rube goldberg machine. think of software like that. flashy, pretty, distracting, and a few WTF. if you break it all down it makes sense bu
Re: (Score:3)
I spent most of my time at my previous job automating tasks for other people so that they could stop doing the repeated and error prone work.
Then I got laid off because the bean-counters at central corporate did not believe I had enough "billable hours". The corporation actively encourages you to work slowly and inefficiently because they make more money that way...
And they wonder why the offshore sector in Norway crashed a year ago with the oil price no longer inflating profits.... sigh
Re: (Score:2)
I spent most of my time at my previous job automating tasks for other people so that they could stop doing the repeated and error prone work. Then I got laid off because the bean-counters at central corporate did not believe I had enough "billable hours". The corporation actively encourages you to work slowly and inefficiently because they make more money that way...
So in other words you spent non-billable hours to reduce your colleagues' billable hours and got laid off? Shocker. Here's the rub, first you must provide value unless you're one of those credit-stealer types. Then you make sure people recognize that value, if nobody knows nobody cares. Then you make sure you're compensated for that value. That goes for the company, same as you. Did your company's clients recognize the value they got by your automation? Was the company compensated through winning more contr
Re: (Score:2)
Fixed price contracts.
Sending 3 weeks manually verifying a couple of hundred excel sheets against other excel sheets netted the same payment from the customer as the automation I created that cut that down to 2-3 days.
Re: (Score:2)
Agree that a proper implementation of Agile - meaning a balanced approach where the product owner and business plan the backlog (thus supporting all user requests), and the dev team agrees on how much work they will do in a given sprint. Both sides must be empowered: the biz to prioritize items and developers to decide which of those will be completed in the next few weeks.
Like an architect and a general contractor. This is a solved problem in other fields.
Re: (Score:2)
The problem with Agile is that it effectively does away with estimates for when things will get done. Now this is fine for developing a running website, in which development velocity is king, and it's simply better to delay a feature rather than write throw-away code to make it work for a demo. However, it works very poorly for anything hardware related, or in which there are shows to make, or where there is a marketing roadmap, or senior management is impatient, or basically anything in the real world.
So i
Re: (Score:2)
Does anyone still report bugs on Firefox? I gave up a long time ago, myself, no one there ever seems to give a shit, and you end up getting in inane arguments about why the bug isn't a bug.
(Discussions in places like slashdot are much more reasonable.)
Seriously: I have the sense that it's finally sunk in that the various clever-clever things Mozilla's been doing over the last ten years have been driving people away, and it could be that they're getting back to "empowering the user" instead of "empower