The Sad Graph of Software Death (tinyletter.com)

An anonymous reader writes: Programmers, raise your hand if you've been on a project where bugs keep piling up, management doesn't dedicate time to fix them, and the whole thing eventually bogs down. Gregory Brown summarizes that situation in one simple little graph from an issue tracker, and discusses why so many companies have problems with it. "This figure tells a story that is no way surprising to anyone who has worked on software projects before: demand for fixes and features is rapidly outpacing the supply of development time invested, and so the issue tracker is no longer serving as any sort of meaningful project planning tool. In all but the most well-funded, high functioning, and sustainable businesses — you can expect some degree of tension along these lines. The business side of the house may blame developers for not moving fast enough, while the developers blame the business for piling work on too quickly and not leaving time for cleanup, testing, and long-term investments. Typically, both sides have valid concerns, but they don't do an especially good job of communicating with one another." What methods have helped you deal with situations like this? What methods haven't helped?

Comments

Management

[Lisias]

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

[Anonymous Coward]

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

[Etherwalk]

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.

Ideally, sure, but IRL you can have people who are *great* at management and don't code very well, and a limited budget and time so you might not get great management and Knuth-like coding. Basically you're asking people to be competent in two areas and there's a limited supply of people, so you don't want to over-optimize in either direction: soft skills matter even more for manager jobs than they do for programmer jobs, after all, so you might hire someone as a manager who you wouldn't quite hire as a programmer if they have great soft skills and know enough programming.

Re:Management

[Anonymous Coward]

An ideal manager is an effective resource allocator, while the worker is a resource consumer. A union (in countries with effective unionisation, e.g. Germany) acts as negotiator between management and worker, ensuring an infrastructure such that the worker has every incentive to remain at the company and keep themselves well-trained so as to maximise profit for the company.

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.

Re:Management

[sunderland56]

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:Management

[Opportunist]

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:Management

[Anonymous Coward]

Managers don't run projects, they manage the people who do. Project managers run projects, product managers (in Agile) set goals, managers who run projects and set goals are from a different era. Not saying there aren't companies stuck in this time warp, but they're typically not IT based and don't deliver software solutions (though they may be running a few (usually in classic ASP or web forms). Ex. Safeway cash registers don't run a fully implemented DDD MVVC solution, however an e-commerce might strive for this.

Re:Management

[Anonymous Coward]

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:Management

[Lisias]

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". What exists is communication to the wrong audience.

Re:Management

[Lisias]

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: Management

[Anonymous Coward]

Sounds like it's time to look for another job.

Re: Management

[Anonymous Coward]

I agree. This one 'ends' in a few months. Just time to find another one. Going all the way to the end as everything in my area is 20-30k less than what I make now...

Re: Management

[Anonymous Coward]

Similar story here. First off on the whole my boss is great. But he's a designer in his early 40s so his web designs he gives me are desktop first and don't always lend themselves to a mobile view. I don't mind putting in long useful hours when we r busy but I start working 9-5 when he gives me shitty designs that take too long to implement and suck the life out of me and the fat out of the project. But he is learning.

Re:Management

[bigtreeman]

Management are non-productive cost overhead,
workers are profit positive real wealth creators,
comrade !

Re: Management

[Anonymous Coward]

Depending on the size of the project you will have more or less need for meetings. The idea that you can do without works by stars who can get others deliever needed info to their table without meetings participation - something that costs time of somebody else. This said meetings can be better organized than they usually are.

Re: Management

[Anonymous Coward]

Even in germany there are hardly unions in it companies.

Re:Management

[tlhIngan]

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 makes sense and allocates resources to those tasks. If a task is already being done while a request comes in for it, the manager handles it.

Sometimes a manager has delegates, like a project engineer (someone who is technically skilled in the project and knows it inside and out) to whom they offload the more technical questions to so as to avoid bothering the rest of the development team with the questions, or if the team is too large, to have the project engineer assign it to the right person.

Customers can be quite demanding, and there has to be effectively a firewall between development and sales - aka the manager. Customers tell sales what they want, sales relays it to the software team manager who aggregates and works with sales to figure out what people are really wanting. The manager then takes those requests, then works with a project engineer to figure out how best to schedule and do do the work to implement the requested feature. The project engineer (who may be the manager) then works with the developers to actually implement the feature - to do a proper spec, design it, implement it, test it and prep it for release.

Because when sales talks directly to developers, chaos erupts.

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.

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 because you're the knowledgeable one, then you've got a choice - you can tell your managers you don't want to be in a management position in which case you can sink back to a role of a developer, or you can adapt, realize your career has turned from lowly developer to manager, and start managing.

Looks like you want the former, which is perfectly OK - there are plenty of people who don't want the management track and want to stay technical. Depending on your company, there may be opportunity to advance to a high level technical person (architect or so). without management responsibility.

If you do want to pursue the management track, the first thing you need to dispose of is yourself as a #1 resource. You can develop, but you'll have to give the bigger chunks to someone else. As a side effect, you can also assign the crap jobs or tasks you don't want to do to someone else (too busy to take care of this). But you need to realize that you won't be in the code as much, but will be able to make the small changes people want.

Me personally, I've been pushed into that track as one of the top level of software developers where I have to manage a small team of people. I realize how much time meetin

Re:Management

[altor31]

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.

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.

Hide information to the team is a no way.

Re:Management

[leuk_he]

And most managers are doing some kind of stand up board nowadays. Put that graph from your bug tracking system up there, and it might get more attention.

Some of these bugs are old now, but are never removed. They either need to be removed, or removed from the bug tracker. Bugs that still are in the state of "it does not work" with enough detail. need to be removed.

Re: Management

[Anonymous Coward]

I was one of the few that worked "both" sides, had a clear and in depth understanding of TECHNICAL and OPERATIONAL/FUNCTIONAL requirements; how to meet & exceed EXPECTATION Management, deal with subsequent SLA's and SLA Renewals. Once your an & in a "cycle" you never stop...

Re:Management

[JaredOfEuropa]

Good point about budgeting for bugs.

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 analyst doing the preliminary budgeting: they are afraid that showing high maintenance costs on the estimates will get the project nixed by management. And they are right to fear this: some departments have a separate budget for maintenance (one amount for all software they are responsible for) but it's always insufficient. And of course listing high maintenance costs for a new project means that the department budget for maintenance would have to be adjusted mid-year, which is a horror few bean countrs are willing to comtemplate much less consider. That's a good way to get your project proposal shot down.

In some cases they didn't even budget for enhancement requests. They figured that v1.0 of the software would be bug free (we're testing after all, right?) , would do exactly what they wanted, and that there would be no changes in the business in the foreseeable future.

Re:Management

[Cederic]

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:Management

[Anonymous Coward]

You hit the nail on the head. The management technique I see these days is to use firing as the first resort... not the last. For example, one job I had, a few people has lapsed MCSE certs. Well, management came in, fired people for "not maintaining adequate training" for the certs the contractors/employees had to pay for.

In my experience, there was never any management feedback. Only pink slips, then the most vicious stuff, as well as the most trivial came out. When the PHB gets asked why it wasn't brought up earlier, they just get mad.

But, welcome to the modern world. Employees are fungible, while the fresh MBA will live in a company forever and do absolutely nothing other than axe staff as his way of maintaining control. Management, as taught, is out the window. Conflicts between co-workers? Ignored until it causes enough ruckus that top brass get involved and demand heads roll.

There are good managers, but you won't find them in companies that have job openings, mainly because most of the latest wave of companies don't really give a shit about the people working for them.

Re:Management

[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.

Re:Management

[Hylandr]

>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 because you're the knowledgeable one, then you've got a choice - you can tell your managers you don't want to be in a management position in which case you can sink back to a role of a developer, or you can adapt, realize your career has turned from lowly developer to manager, and start managing.

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

You're smoking crack. This is in no way ' you got promoted to manager'.

I know this guys plight, it's not a fun place to be.

Re:Management

[jbengt]

Employees are fungible, while the fresh MBA will live in a company forever and do absolutely nothing other than axe staff as his way of maintaining control

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.

Re:Management

[Z00L00K]

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:Management

[Anonymous Coward]

Management are non-productive cost overhead, workers are profit positive real wealth creators, comrade !

Bad management, for sure.

Good management has a crucial hole on preventing development efforts corrosion.

I agree that no management is better than bad management - but good management is way better than no management

(Lisias, trying to login without success on this buggy site)

Re:Management

[KGIII]

I'll thread this under here - I saw your comment below. I finally got the error on a box, the login issue. I resolved it by simply deleting the Slashdot cookies (all of them - there are quite a few) and any local storage associated with the site. Then I logged in again and all was good. I suspect it may have something to do with them adding https for the login.

Re:Management

[Lisias]

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. :)

Re:Management

[sysrammer]

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

[sysrammer]

A variation of "It's always easier to ask for forgiveness than permission."

Re:Management

[Anonymous Coward]

> They dont care then I dont.

The reason for why I looked for a new place to work at.

Re:Management

[Anonymous Coward]

Meetings are crippling to productive developers.

This site, and the industry in general, used to be a place for people who knew what they were doing and preferred to be left alone to do it. Unfortunately, there has been a serious push to inflict a social mindset and all that it entails. Thus, we are overwhelmed with people who love to talk, can't understand black-and-white instructions*, or both.

*And I don't mean this code formatting idiocy that's taken hold of so many development teams. I mean when you hand people a spec sheet for a dozen identical servers and they all end up wrong in different ways.

Re: Management

[Anonymous Coward]

Managers should be required to have recent development experience. You cannot manage what you don't know. We all know how that ends. No other business has technology challenged (and proud of it) managers.

Re: Management

[Anonymous Coward]

I've worked under several styles of management, my personal style is to organize and prioritize according the information I've been given. Requesting clarification from my manager if needed. That said, historically many of our managers have been Cowboys. No planning just jump into the middle of a project and drag team with them. Worse, after end of phase 1, project pretty bad but manager already bored and ready to move on to something else.

Since we have a mix of manager, official projects with deadlines must compete with cowboy bob's idea of the week. "Oh, didn't want to take your time to invite to the meeting in that." We also deal with departments that are over managed so there must be some point that's not at either extreme.

Re: Management

[Anonymous Coward]

Some is neccesary as some will not get anything done. Administrators in the other hand, could lose the majority.

Re: Management

[ananamouse]

The only reason you are there it to take all the money they will give you. As long as they put kibbles in your dish wag your tail and say Arf. It will sink in when they stop and you leave them a present in the middle of the carpet in front of the sofa.

Re:Management

[Anonymous Coward]

Try reading John Ringo's "The Hot Gate". A great explanation of the South American mentality.

Re:Management

[Lisias]

I'll thread this under here - I saw your comment below. I finally got the error on a box, the login issue. I resolved it by simply deleting the Slashdot cookies (all of them - there are quite a few) and any local storage associated with the site. Then I logged in again and all was good. I suspect it may have something to do with them adding https for the login.

*THANK YOU VERY MUCH* :-)

Re:Management

[barbariccow]

I'd rather have meetings and given the chance to voice reality versus sales/owner illusions, than to just be given impossible tasks constantly and be seen as a failure because they don't understand why it wasn't already implemented that way.

The real issue is what leads to having constant meetings in the first place: the lack of understanding of development by the people driving the product. In an ideal world, you'd be presented with some requirements, 1 month, 3 month, 12 month goals of the project, you'd spend some time organizing what is dooable and what is not, and then have long streams of actually achieving it. This sounds... familiar... maybe I dreamt it one day.

Re:Management

[KGIII]

'Snot a problem. Hope it helped. It's thrown some varied errors for a few different people. There's a slightly longer thread in the poll about stamps. No, I have no idea why it is that thread in particular except I think someone wanted to see if they could post in polls.

Re:Management

[phantomfive]

Bugs are a tiny part of the whole.

If you want to keep the bugs down, you can't just expect the architect to solve it, though. You need to provide training for even the lowliest programmer on how to avoid bugs (especially security bugs), because they are adding to the product in a real way. The architect can balance things, but he can't write all the code himself. It's the responsibility of every member of the team to contribute good quality code.

Of course, the architect has more experience and can guide the team on big decisions, knowing pitfalls that have ruined other teams.

Detailed vs Vague

[Anonymous Coward]

One concern of mine with development (I'm a developer) is that business managers, and potentially owners, are vague, while developers need details to get the job done right. With that said, this is what I mean: Business managers tend to expect developers to be magic because they are doing something they don't want (care to) understand, and expect it done like all other workers: you're paid, so do the job I tell you, and do it now.

Developers are in a creative role. (I mean the people who craft the solutions, not the ones who copy+paste code and use frameworks to do 90% of the work.) Therefore, details, and time to get it right, are important. When you pile on features, like piling on ideas, you overwhelm the creative process.

Regarding bugs: That's either an inherited mess, a mess created from poor development/programming, or a mess created from feature creep. When vague directions come from the higher ups (because they don't want to deal with the details/process of making it happen, only the monetary rewards), we get that ever impending deadline that seems ridiculous.

I haven't met many developers who were not enthused to create something great. That's what most of us are here to do. But we need details. And we need time to get it done right... so we aren't chasing after bugs created because someone "wanted it out the door" thanks to their salesperson overpromising. Y'know, can't make the sales person look bad... even if he makes you like a piece of a shit behind your back.

Just sayin'

From experience.

Re:Detailed vs Vague

[peragrin]

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 specific tax information for the state and federal governments. He created a report that outputted the raw data into a spreadsheet and each month manually added it up. By manually I mean he looked at the numbers and typed them into a calculator. The first time I did it. I wrote down the process, and then I created a spreadsheet where a simple import would auto calculate everything i needed for the month. with pretty labels, and history showing the previous months numbers.

I automated a task in 30 minutes that he spent 20 minutes doing every month. He had a dozen different things like that.

Now our ERP software wasn't designed to automate it. if you were good or paid them money they would show you how but it wasn't a standard feature. However it was designed to export raw data easily. with that everything else is easy peasy.

Re:Detailed vs Vague

[peragrin]

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 but why would you put it together that way?

Re:Detailed vs Vague

[omglolbah]

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:Detailed vs Vague

[Kjella]

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 contracts or higher hourly rates? If not, what did you do to the company's bottom line before the collapse? If they'd kept you and laid off somebody else, would they be more profitable now? Because that's how bean counters measure value....

Re:Detailed vs Vague

[omglolbah]

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.

Welcome

[JustAnotherOldGuy]

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

Firing the whole team and hiring a new one

[Anonymous Coward]

seems to be a popular choice for management these days.

Re:Firing the whole team and hiring a new one

[Opportunist]

...when all that had to be replaced to increase productivity is the PHB.

Obvious, really

[Skewray]

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.

Re:Obvious, really

[wonkey_monkey]

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

[NoNonAlphaCharsHere]

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).

Re:Obvious, really

[bigtreeman]

If there were new features being introduced I would expect an exponential increase in open issues.
The earlier in the design process issues are identified, the easier they are to fix.
Just says to me there is a basic problem with how software is developed in general,
whether it is the tools or procedures or the human resources at whichever level.
It has always happened which means we're not doing it right.
Glad we're not building bridges.
I am currently developing something mechanical, using software and embedded and machinery,
I've tried various different approaches over 6 months, with mixed results.
I'm not pushed by clients, who will get my produced output when I fecking feel they can have it.
But it will be right when it hits the shelves. It's a luxury not many get. I'm not driven by profit,
I am loving what I do.

Be honest about technical debt

[desmondbrennan]

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 choice is theirs

Re:Be honest about technical debt

[Anonymous Coward]

No amount of technical debt is acceptable, at least that is the goal. Some times things don't go to plan and there is an unexpected issue(debt), and it's decided to work around it. But I have never written any code with technical debt in mind. The interfaces and layers are always fully designed, it's the implementation of the features that is optional, but the lack of a feature is not a debt and should always be easily to add in later because it's already been designed in.

Technical debt causes code rot to increase. Code rot causes more technical debt. It grows itself. At some point, bugs don't get fixed in a timely fashion, more features are required, and features increase the rate of rot.

Can somebody make that graph for Firefox?

[Anonymous Coward]

Can somebody make the equivalent graph for the Firefox project? I suspect it would look very similar. We've seen Mozilla throw all sorts of new, and completed unwanted, shit into Mozilla lately. Yet there are still many bugs, some of them years old, that haven't been fixed.

But I suppose we don't really need a graph like that to know that Firefox is a dying project. Its ever-dropping share of the browser market is good evidence of that. And contrary to the excuses we get so often from Mozilla's supporters, no, Firefox is not dying because Google is advertising Chrome, nor because of mobile browsers, nor because of any other bullshit like that. Firefox is being thrown away by its users because so much unwanted shit has been forced upon these users.

Re:Can somebody make that graph for Firefox?

[Anonymous Coward]

I stay with Firefox because of features I've grown used to and want, not because of unwanted stuff that I don't use. My complete browsing history is a valuable memory aid. My Feed Sidebar tracks 17 sites with notices by the minute and remembers not to display anything that's already been seen. I block many sites like Wikipedia, Facebook, Fixya, GoogleBooks, etc., from my Google searches. My 4GB Mozilla and Thunderbird manual backups are live across all my machines and haven't failed me in 12 years, besides which, lookups across these SQLite databases are extremely fast. I'm not even interested in looking for a substitute because of what would be lost in translation.

Re:Can somebody make that graph for Firefox?

[doom]

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 "empowering the designer"

Re:Can somebody make that graph for Firefox?

[Reziac]

Yeah, I kinda gave up on Moz bugs a long time ago. Occasionally I put in my two cents when I find a serious bug already has an open ticket, but it's just venting, cuz if the ticket is still open that means it will never be fixed. Some of those bugs are now over 10 years old. And all it takes is one person saying "Works for me" and any chance it'll be fixed is permanently hosed.

As I mentioned above, when I saw the chart my first thought was "Mozilla". Tho on second thought, Moz's "fixed" line would be trending downward...

Idiots

[penguinoid]

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:Idiots

[Anonymous Coward]

oh you know perfectly well. the kind of shops that have

      o massive technical debt
      o poor communication between sales and engineering
      o no reasonable culture around planning and prioritization
      o insufficient testing
      o low technical throughput
      o no broader technical mandate

generally have massive turnover. the people that stay are primarily clock punchers that aren't going to
help turn the ship around regardless.

it takes a real hero of a technical manager to deal with the broader organizational problems, keep their team
focussed, try to address the most important tactical issues, and still spare some cycles to trying to
lift the codebase out of the muck.

realistically i think there is an event horizon beyond which the project just cant be saved

Re:Idiots

[Ichijo]

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

Re:Idiots

[m00sh]

But according to Brooks' law, 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:Idiots

[Anonymous Coward]

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.

To me it seems that not enough money, people, resources is allocated or planned for ongoing maintenance. The features, those are worth money and can be sold to management. Keeping the technical debt from increasing, is way harder to sell. If your lucky, you have enough free time to try to do it, but probably not.

One project I worked on was in the process of being converted to C when the contract I was on was suddenly up and I had to move on. It worked well but it had a couple of big C libraries and then everything else which interacted with those libraries. As time passed the C libraries grew while everything else shrank.

I had spent a few years on the effort off and on to get that far, since the conversion was basically something I worked on when I had time. New stuff was my top priority. I thought I was managing the technical debt fine, or at least as well as I could, since the customers were happy. I warned them that it was not going to be easy to just take over from that point. They understood but there was nothing they could do either as the decision to eliminate contract workers had been a company wide decision.

Long story short, the old group failed at maintaining it and decided starting from scratch was the solution apparently annoying many users. I'd have just finishing what I started a better approach, since at least it kept all the years of bug fixes and special case handling. Either way, not my decision. (I later got a job elsewhere at the same company.)

Is this the path these days?
1) Let the technical debt grow. It gets worse if only one or two devs can maintain large chunks of the project (hence the reason for my original work at converting things).
2) Oh look it is a horrible spaghetti monster of doom.
3) We must kill it and make it better. We have the technology.
4) Time passes
5) More time passes
6) Eventually you get some part of what you had in the first place working. By this point your customers may have moved to a different platform or at least not gotten done much of what they could have gotten done.

Put another way, when is it really better to bin it and start over such that there is a large gap in time before anything truly new is done? Oh I can see binning parts of something, particularly if they won't ever be used, but just cold turkey saying one is going to stop and rewrite a half dozen or so man years of work seems like it rarely can ever be the right solution.

Re:Idiots

[Antique Geekmeister]

> 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".

Re: Idiots

[Anonymous Coward]

Scenario 1. The code is so bad there is nothing to save. End product crashes every half hours and operations last days. The code is full of globals and unsafe threads.

Scenario 2. Big system with many parts with spiderweb-dependencies. Changing one part without touching others is impossible. A lot of duplication in parts.

Scenario 3. Old system runs or is weitten in legacy language. New developers hard to find. Hardware is expensive.

This is when you rewrite.

Re:Idiots

[Carewolf]

> 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: Idiots

[Anonymous Coward]

Those "extra tasks" frequently have non-trivial interdependent relationships with other tasks. -PCP

Re:Idiots

[khallow]

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. The second obvious rebuttal to your post is that you didn't read the fine print.

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, low communication overhead which works through said "issue tracker". Finally, a huge portion of the workload are highly divisible tasks.

In other words, the coiner of the aphorism which you use, explicitly provided a number of exceptions, all which apply to some degree here, for when the aphorism didn't hold.

Re:Idiots

[david_thornley]

Thornley's law: 99%, at least, of project failures are the fault of management. The people doing the actual work do so in the environment provided by management, doing things as told by management, and sometimes work to unrealistic deadlines set by management. If there are insufficient people to do the work, management needs to do something about that, such as hiring or transferring more, or extending the deadline. If there is insufficient time, then management is at fault for making bad deadlines, providing too few developers and/or resources, failing to foresee something until too late, or letting the code base etc. get into a condition where it is not possible to react fast enough.

fred brooks to the rescue

[turkeydance]

it's saturday, and that's all i've got.

Re:fred brooks to the rescue

[Bite The Pillow]

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:fred brooks to the rescue

[Anonymous Coward]

Can't you read? Didn't you see the previous story about "flexible" hours, i.e. virtually never leaving work, making you unhealthy?

He said, IT'S SATURDAY for crying out loud. MOST of us have to go slouching back to our BS jobs day after tomorrow.

Try to give it a rest.

Re:fred brooks to the rescue

[sysrammer]

Woof. One thing that's needed on the entertubz is a thick skin, huh?

If you try to cut bread with a spoon...

[Shadow of Eternity]

...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.

Re:If you try to cut bread with a spoon...

[Anonymous Coward]

The sad graph of slashdot death would explain this perfectly

Still no images, Slashdot?

[wonkey_monkey]

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:Still no images, Slashdot?

[NoNonAlphaCharsHere]

Here you go.

Re:Still no images, Slashdot?

[Bite The Pillow]

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

Re:Still no images, Slashdot?

[Anonymous Coward]

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.

Why? I didn't even read the entire headline before I scrolled down to find something to reply to.
Pictures would only slow me down.

Re:Still no images, Slashdot?

[Anonymous Coward]

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.

Why? I didn't even read the entire headline before I scrolled down to find something to reply to.
Pictures would only slow me down.

Same AC here.
Oops, I forgot to call you an offensive name. Oh well, it just doesn't feel right now.

Tell management the system needs debugged.

[Anonymous Coward]

Before adding new features, debug the old features. If you're adding features when your system isn't debugged, of course it is all going to come crashing down. You'll find yourself hitting an old bug when debugging new stuff, and it is distracting to jump all over the place coding. Focus on one part of the code at a time if you want to do it right.

The other side of the coin

[Jeremi]

... 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....

[cant_get_a_good_nick]

DUCK

Re: Third rule in a crisis situation....

[Anonymous Coward]

Goose

Re: Third rule in a crisis situation....

[JustOK]

Wombat.

Re:Third rule in a crisis situation....

[Z00L00K]

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 small short meetings that the important decisions are made while in the large meetings there's a lot of talk and little done.

Re: Third rule in a crisis situation....

[Anonymous Coward]

Maverick.

Re: Third rule in a crisis situation....

[cant_get_a_good_nick]

I guess nobody but me remembers that movie.. yeah, it was horrible

Confluence

[Anonymous Coward]

This is why Confluence 3.5 died. RIP.

Re: Obvious, really. Transferred support to India

[Anonymous Coward]

Saving money by using offshore developers.

Start by categorising bugs

[mikael]

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:Start by categorising bugs

[JaredOfEuropa]

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, which are small enhancements, or larger feature requests? If you get a lot of enhancement or feature requests, it's time to talk to the business and make sure that the inflow of new requests slows down at least if they can't afford to stop it completely. Ask the steering group to approve each request and pass only the high priority stuff (if there is no steering group at this point, then you have bigger issues). If you are getting many small requests, then perhaps these can be combined into larger, more coherent requests. That in itself will not only help your ticket count, but it'll also help the steering group to affix the right priority, and help your designer to better make sense of what the business actually wants and design accordingly. In this case, what you may need is a business analyst on your project or embedded in the business to help draft better enhancement requests.

Then start a more detailed categorisation and prioritisation. If there are a lot of nice-to-have low priority items, suggest to management that you take them off the tracker, archive them, and have a separate project to address them at a later time if management still feels that there is a business case for them. At this point you should have stopped new nice-to-haves from being submitted. Of course this is just a cosmetic measure, but if you can make a sizeable dent in the number of open tickets it will be a huge morale booster, and it makes priorities clear. For the remaining items, I would suggest using sprints and get the business and the development team to agree what'll get done in each sprint. At this stage it is crucial to get the business involved in the prioritization of the work in order to manage their expectations and get buy in, and Agile can be a good way to achieve that.

Finding out where the bugs are coming from is part of the long-term solution, but it does need to be addressed following the previous measures. Get the time and if necessary resources to find the root causes of these bugs, and start a process improvement track. If there is a fundamental issue such as software architecture or tool chain, you'll have to present a case to management to redesign or refactor the software, or re-tool. At this stage you should be able to do a cost estimate for this.

There's an easy way to fix that

[Opportunist]

1. Fire all managers.
2. With the money this frees up, triple the programmer headcount.
3. Profit.

Re:There's an easy way to fix that

[Krishnoid]

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

Re:There's an easy way to fix that

[Anonymous Coward]

Indeed, because it's so non-disruptive to add two staff members who haven't worked together before and don't know the product for every staff member who does.

Re:There's an easy way to fix that

[Opportunist]

Why the fuck should I bring the arsonists back when I finally put out the burning building?

Re:There's an easy way to fix that

[Opportunist]

If your current programmers aren't already working 80 hours a week, you can also use the money to pay them the double overtime cost. The money you save by getting rid of the wasteful sponges should easily cover that.

Re:There's an easy way to fix that

[Oligonicella]

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:There's an easy way to fix that

[Z00L00K]

No, arsonists are productive, management overhead is like pouring cold tar into a machinery.

Re:There's an easy way to fix that

[Opportunist]

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

[phantomfive]

These are my two favorite books 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.

Re:Be professional

[Dutch Gun]

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 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.

In cases like this, the root cause is very often some architectural issue with the software that somehow makes it rather fragile and susceptible to creating tricky bugs. Unless a company/team is willing to dig deep and fix these underlying issues, often involving much short-term pain and a temporary regression of bugs and features, the negative trends will simply continue. I've been involved in several of these projects, and the root cause was always fragile, messy code (and yes, I was guilty of writing some of it). In hindsight, in nearly every case, it would have been worth taking a very large step back, declare "this isn't working", and taking some serious steps to fix it. Instead, human nature being what it is, we almost always try to do the minimal amount of work to patch things up just enough to fix the symptoms, when in fact the patient is bleeding out internally.

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. You can't just endlessly rewrite code without moving forward or course, and tinkering with working, stable code for its own sake is a horrible idea, but every once in a while, it's a great idea to go back and make sure you're not leaving too much nasty detritus behind. Code detritus has a way of multiplying, because it encourages NEW code and features to be written in the same style and methodology as the old.

Re:Be professional

[phantomfive]

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 improve their code.

Re: Be professional

[Anonymous Coward]

What bugs?

Well known problem; well known solution

[Hairy1]

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.

Re:Well known problem; well known solution

[Antique Geekmeister]

> 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:Well known problem; well known solution

[Antique Geekmeister]

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:Well known problem; well known solution

[sysrammer]

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

Re:Well known problem; well known solution

[gidyn]

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.

Is this the manpage for systemd?

orthodoxy

[superwiz]

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 try to farm people and keep on top, they don't realize when poison pills get introduced into the code because they are often the ones doing it. If you see a manager who thinks that Emacs (fine or vi) is the only way to develop code, you are seeing one of those. Progress in technology means faster and more effective ways of creating new technology. Orthodoxy is people trying to suck the blood out of the young while they are still young and set them on the way to thinking that the only way to advance in career is riding on their coat tails. Development is transformation of problems into solutions. It means culling the crud work -- not getting more effective at doing the crud work.

Re:orthodoxy

[Anonymous Coward]

I don't know why you think you had to bring in emacs/vi.
When it's just writing code, and it's a code-base/framework you're really familiar with, a plain editor gets rid of all the distractions, allowing you just to write.
Quite a few authors like to write with the plainest, distraction-free interface possible, too.
(plus, emacs/vi can make almost fully-featured IDEs, just without a GUI)
There is also the issue that most IDEs are utter crap technically: Take the search function. In the time it takes e.g. eclipse or VisualStudio to complete the search I can open a terminal, write a grep command, filter out some false positives and open the file I wanted. With the caveat that grep does not work for code-bases where you e.g. have 10s to 100s of functions with the same name all over the project.
This could be fixed (e.g. they could use a real fast, text-only approximation giving you the result of grep-style search and then filter out by more detail), but unfortunately IDEs are developed (and possibly used) by people that think it's ok to break a programmers flow by having them wait for 30 seconds regularly.
Btw. building is also a good example: in many IDEs the editor becomes unresponsive/unusable while building, builds are either impossible to cancel or take minutes to do so etc.
IDEs are a typical example of what this article is about: features are added over and over, but nobody ever gets around to make the base features work flawlessly.
It can still make it the better product, but its usefulness is highly degraded.

Ours "kinda" looks like that

[Anonymous Coward]

But not quite so pronounced. Plus, the CIO (company founder) regularly kills off tickets he deems irrelevant.

Though, I'm pretty certain the company I work at is a scam. Our numbers are terrible and plummetting, yet presentations from leadership are always as glowing as can be and I know the majority of employees aren't drinking the Kool-Aid anymore.

Re:Ours "kinda" looks like that

[Anonymous Coward]

I'm pretty sure I work at the same company as you do.

Different Prioritization

[mongothesecond]

Having worked in a couple companies with this kind of problem, I think the issue is that all too often dev groups dont directly build their prioritization in terms of every single item tied to a piece of revenue. Gambles or demands to land new business frequently beats investment in retaining customers or lowering operational costs. I think at least two business realities compound this issue. One, salespeople on quotas set priorities in some dev groups, and they are inclined to overcommit and gamble. Two, "Lean startup" and "minimum viable product" language is great for early rounds of funding and tactical direction, but I have not yet worked in a company that had a clearly articulated line in the sand to evolve from MVP to "enterprise software". Sooner or later, customers want stable, fully featured software. Report generation is my personal albatross.

SAFe

[nradov2444]

Scaled Agile Framework offers a solution to this problem. I've used it and it works, but it needs full support from senior management to be effective.

Re: SAFe

[nullchar]

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. Of course the team needs to give demos and have retrospectives, all with business support.

Agile done right implicitly solves the article's problem, but half-assed Agile sucks for everyone.

Re: SAFe

[Anonymous Coward]

And I suppose you do agile "right"?

Re: SAFe

[StevenMaurer]

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 instead what happens is that many companies do quote "Agile" unquote, in which an Agile process is a synonym for no process. Generally engineering is running along happily using Agile to stack rank things, but overall estimation of when this stuff is getting done is done at a higher level by people who are often relying on pure guesswork. Furthermore, in such a system, it invariably ends up that delays are not accounted for. Stack ranking one thing as your #1 item absolutely means that some other item isn't being worked on, but that rarely makes it back up the management chain.

Program Management is the discipline required to fix this, to insure that the waterfall-esque marketing roadmap and the engineering development stack rank is in alignment. However it also requires senior management buy-in, and talented program management, neither of which is common.

I guess the only think you can really say is that everyone is in the same boat. There are no companies run absolutely perfectly. And if they are, they grow so much that they can no longer be.

Re: SAFe

[sysrammer]

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: SAFe

[ripvlan]

Well - "you're doing it wrong" ;-)

Seriously though - I agree that there is no Right Way - it is what works for you. And for software anyhow... Agile works fine for getting things done - even by a specific date. This is where tools such as t-shirt size and velocity comes in. The trade-show example you mention is a Release - and using a burn-down chart allows you to know what will be done by that date. We ask ourselves during Release planning how much scope are we likely to accomplish. Granted many features come in at times as immutable feature-sets -- but they shouldn't be. Story scheduling really helps break things down so that multiple priority feature-areas can move forward in a strategic manner.

Agile is more about understanding where you are at now - and where you are likely to be in a near future. Everything else is scrambling, running around and wishful thinking. Story Points (or Value points?) are money - the PO has X dollars to spend (velocity suggests how much per sprint) - so the PO can (hypothetically) go to the backlog and pull out X dollars of Stories that they wish to have finished in the release (and the Release may be the trade show). I use Release in a soft-definition here.

I worked on a hardware program and used Agile. We had a date based upon lead time to get the final specs to the supplier - we knew that this date was "sprint 20" and prioritized as necessary to get that work done first. You can iterate and refactor hardware - granted harder to do. We iterated with Modeling on software, prototypes, requirements, and final design. But there is that set-in-stone phase - hw & agile needs a technology shift (3D printing, printed circuits for prototyping etc).

It is hard to keep the pace and stick to the concepts of Agile. I think it pays off though. Done is the hardest part. Not having a firm definition of Done (and sticking to it) is usually what causes a Release to go beyond the desired goal.

Iron Triangle - You can define Resources, Time, or Features/Quality. Resources are usually fixed - so is Time. Therefore the only knob you can adjust are what features you build (or their quality). More Features Less Quality or Fewer Features More Quality. Ratio: Features/Quality :-)

The one place that I haven't seen Agile handle well is multiple teams/disciplines across a large organization. This still seems to be best served with a Gantt chart and more traditional PMs. Esp if one team needs training or the like from another team - anything that has a hand-off and the resources need to be scheduled (all remote employees will be in town during week XXX for training) - this can't be "Agile" because plane tickets and rooms to book etc.

 

Bingo!

[HornWumpus]

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 to bail in the first week at a new job. You were looking for work when you found that place.

A manager who is used to 'his team' taking it in the personal life isn't going to change his ways. It's mostly working for HIM/HER.

Recognize the root of the problem and if you can do anything about it besides leave.

Re:Bingo!

[Hairy1]

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:Bingo!

[Anonymous Coward]

You can push a company hard (as I have) to apply software discipline (tests, deliverables), and to argue for an architecture instead of a Big Ball of Mud. But it's hard to fight the desire for instant gratification (generally focused on UI tweaks, small features, SEO optimizations [that do little], etc.). If you don't take software seriously, then don't have pretensions of becoming a huge enterprise.

I've had success over the course of three years, but I think I've pushed my current organization about as far as it is capable of going. If I left, the first thing to go would be the tests (which catch things every week). And it will be back to the "Jump!" "How high?" culture.

Re:Bingo!

[Anonymous Coward]

The problem is that all companies are dysfunctional in some way. The problem as described is very common.

I would rather join a company which is has dysfunction, has problems, but at least has people self aware enough to listen.

But therein lies the rub. Most organisations, that are dysfunctional in the way that you say they are, simply are not self-aware enough to listen.

It's like the Dunning-Kruger effect. If an organisation were aware enough to recognize it's own dysfunction, it could and no doubt would do something about it. The very fact that the dysfunction exists, and continues to exist, indicates that the organisation either isn't aware of the dysfunction, or is aware and is actively ignoring it.

Either way, you telling the organisation that they have a dysfunction that needs fixing isn't likely to go down too well.

Re:Bingo!

[Anonymous Coward]

You are correct, but part of the problem is who takes the credit for the fix. If you have incompetent (project) management (and you are -senior- SE), you basically become the (project) management without the credits and title. Hey shouldn't we plan it this way, or shouldn't we use this tool to manage sprints, shouldn't we do stand up meetings, since all our 10 minute meetings turn out to be one hour rants. Shouldn't we write better documentation and tutorials to get new developers faster up to speed with our software stack, shouldn't we do a bug support rotation so everyone gets accustomed to all the code and not guy gets all the bug work and can't move forward with his work, etc, ...

Re:Bingo!

[HornWumpus]

All companies are dysfunctional in some ways != all companies are equally dysfunctional.

When there is nothing you can do about it, just leave. There are, in fact, better places with better cultures and results.

When you find a 'ball of mud' you can pretty much guarantee you won't find managers doing much listening.

The people that put forth heroic efforts to protect their PHBs from the consequences of their decisions are part of the PROBLEM.

Stop implementing new features

[emorning]

The author challenged the readers to make a single change that would have an immediate effect without writing a single line of code. I can only think of one... immediately stop implementing new features. That would keep the open/close ratio from getting much larger without any coding. But how to make the business case for doing so? My argument would be that the graph shows that their current systems are broken and worthless. The business can recover their investment in the current systems by taking the time to fix the open issues and removing broken functionally that's not needed.

Tell them whatever they want to hear.

[Anonymous Coward]

Then ignore them and do what you need to do.

Its usually a business decision

[TomGreenhaw]

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 maintenance investment. Admittedly, it's no fun doing a half-assed job, but sometimes you just have to hold your nose and do the minimum.

All too often business decision makers don't understand the tradeoffs and value of software maintenance. Equally, developers ignore the business aspect of their creations and cry for purity from their ivory tower for programs that do not warrant further Investment. Both camps have to learn to take the wider view.

I've learned to advise that when software is developed, a maintenance budget be crafted from the inception of the program and projected through the entire program's expected life. Having this planned in the beginning of a system's lifecycle promotes satisfaction, success, quality and long life.

at least partly a project management problem

[david_bonn]

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.

Re: at least partly a project management problem

[Anonymous Coward]

Joel Spolsky likened the giant list of bugs to an keeping inventory: There's an overhead cost just from it being there.
http://joelonsoftware.com/items/2012/07/09.html

When you look closely you realize that months or years of work has gone into preparing those bug reports, and you ask yourself, how could we have 3000 bugs in the database while our product is delightful and customers love it and use it every day? At some point you realize that you’ve put too much work into the bug database and not quite enough work into the product.

• Suggestion: use a triage system to decide if a bug is even worth recording.
• Do not allow more than two weeks (in fix time) of bugs to get into the bug database.
• If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back.

Give us direct access to users

[SuperKendall]

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:Give us direct access to users

[Anonymous Coward]

Hilarious post! You must be 23 years old.

If you think you don't have time to do shit now, wait until the customers know your email address.

LOL, give us direct access to customers, what a hoot!

Youth is wasted on the wrong people.

Re:Give us direct access to users

[Antique Geekmeister]

> 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 get used to always getting the chief engineer.

Re:Give us direct access to users

[Anonymous Coward]

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 been distilled into rigid, overly verbose specifications with varying levels of vagueness and utility.

Re:Give us direct access to users

[ByteSlicer]

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 back with things like: user X wants a button here that does Y. Then I'd say, hmm OK, and what is he trying to solve/improve by having that extra button? What are the use cases? Then the guy would go back, and it would ping-pong a couple of times. In the end it was often more productive to go talk to that user directly.

There are caveats though.

End users often don't know what they want exactly, only that they have a certain frustration that they want fixed, and they will often propose what they think will solve it (very often a magic button). So you need to take the time to find out what it is they really need, and then see if there is a generic solution for it that fits in your architecture and process flow, that might be useful for more than one user.

They also often have a very narrow view of the problem, so you have to inform them what the impact is of their new feature on other users or other parts of the software. Quite often they didn't think it through and even left big holes in their own use cases. They often request features they need NOW, so you always have to weight the costs against the benefits.

Direct user interaction also helps setting realistic expectations. We can quickly guess if it will be a complex feature, explain why it is so complex, and why we probably won't be able to implement it. End users often expect the software to perform magic, using incomplete data to perform error free tasks. Things a human often cannot even do given all data and experience.

This all leads to less user frustration, and an overall more streamlined workflow.

Re:Give us direct access to users

[phantomfive]

I don't think it's people skills exactly, it's something more like this and this.

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:Give us direct access to users

[SuperKendall]

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 spend time with customers to learn what will actually help them - and to a point a different responder was making, that does not always mean to do what the customers are asking you to do.

Re:Give us direct access to users

[Anonymous Coward]

"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...."

I cannot disagree more. What the workplace has done is turn unsocial programmers into antisocial programmers. We're not allowed to interact with customers and we're not allowed to make even the tiniest decisions on our own. They both stem from micromanagement and have many negative implications. We're simultaneously robbed of opportunities to excel and punished for problems dumped into our lap. No questions or suggestions or, God forbid, criticisms because that's antisocial!

For the life of me, I cannot fathom how some organizations expect to achieve even a mediocre result with the kind of shackles that they put on good programmers. It's like they don't really need working software because excuses from the talkers with occasional lynchings of "outsiders" are an acceptable substitute...

Developers as cogs in the machine.

[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/skype.
4) Sidetracking us like this would result in our current product withering.

Its not just software....

[Anonymous Coward]

Greg,
      In reality this trend is being seen in all of engineering in both hardware and software development. This is trending like this in both Commercial and Defense Contracting practices. Don't feel you're alone in this. I think we may be seeing another symptom of the brain drain. All of the competent baby boomers are retiring and peeling back the onion to show what is left of the people that just "rode the gravy train" and now are unable to step up to fill the roles left behind.
          In short we've a severe lack of leadership, people willing to step into that role because there is no merit structure for it, and an entrenched environment where there is retribution for "rocking the boat". The only silver lining is to allow the Mid-Career folks (probably Gen X and Ys) to step up and make positive change and offer leadership without retribution, and a revamped merit system that will influence that for the positive.

The next 5 to 10 years is going to be a wild ride.

Management

[darkain]

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...

Got it good

[JBMcB]

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.

Re:Got it good

[Anonymous Coward]

JB,
        I envy you. All of my management don't have an engineering degree, or haven't done engineering in decades. All they have to fall back on is process, giving the rest of us trying to get work done headaches. They've no real leadership skills or sense or prioritization. They've no tools in their skill set to manage scope creep. That leaves the rest of us engineers to fend for ourselves. I hope your ideal environment continues.

One Possible recipie

[Anonymous Coward]

You need a combination of tools, Experience in reporting issues, and Management that will actively seek out issues, asking the right set of questions.
If you're a lead you need to get your butt out of the meeting room and sit with your developers asking pointed questions with no retribution. IF you do that successfully, you will build confidence in your staffing that they can come to you to report issues. On the other side, you need to demand quality issue reporting with potential avenues for resolution. If run rules are clear and set correctly this combination works.

Getting in the working area with the developers once in while will garner respect among your development staff. Offer them a way to report and work issues will do some things:
1) Make them feel like a professional
2) Feel they make a contribution
3) Provide an open dialogue with engineers of different disciplines

THIS TAKES MONEY. If you allow issues to get sidelined (in my experience sometimes for years) you're retention, morale, and quality will suffer.
Grow a pair and PRIORITIZE!!!! If you can't do that then everyone will chose their own uncoordinated path.

Figure Out What Happened on April 7th

[dcollins]

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.

Re:Figure Out What Happened on April 7th

[Anonymous Coward]

If I had to guess, April 7th was the release date.

Here's what should happen but doesn't

[the_Bionic_lemming]

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:Here's what should happen but doesn't

[the_Bionic_lemming]

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.

Re:Here's what should happen but doesn't

[Anonymous Coward]

"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."

Allow nobody to make promises on your behalf - unless you were consulted.

If someone does, ignore any flack or pressure because it was an illegitimate promise.

In short that means *ignoring outcomes* because clearly you were *not in control*.

If you feel unable to ignore that flack, try to push it up to the next level to obtain justice.

If that fails (which often can because the asshole injustice *is* from upwards), then your organization is toxic and you've just acquired a kind of *prescience*. You know where assholes will bring this company culture to - time to GTFO ; with a plan.
Start finding a new job.
Think about what happened.
Gain wisdom from it.
Share it.

 

Re:Here's what should happen but doesn't

[Anonymous Coward]

... Stop blaming me.

Step away from the American model of manager = leader. Anyone more interested in earning brownie points than in supporting his team, isn't a manager, just a poor leader. What such a culture really says is, the ego/profits of the board of directors/sales department is more important than efficiency of the entire organization. Then again, if efficiency was important, the managers would help their teams do it right the first time.

What management does

[sjbe]

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:What management does

[Anonymous Coward]

Your list suggests that you aren't doing enough delegating, even if you're at a small company.

Re:What management does

[Anonymous Coward]

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?

Yes.

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 monkey on convincing people otherwise. :-)

Managers should MANAGE. Nothing more.

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

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:What management does

[Lisias]

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:What management does

[Lisias]

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:What management does

[Lisias]

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

Re:What management does

[Lisias]

(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 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.

Context

[jemmyw]

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:Context

[omglolbah]

"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

[zmooc]

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.

Re:This is not the sad graph of software death

[Anonymous Coward]

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".

No, that's *not* normal. If you're not going to fix these issues, you should resolve them as "won't fix" or similar, logging the reason why. You can always reopen them later if the situation changes.

Leaving huge amounts of issues like this open makes it hard to find the open issues that are solvable. So it's a sign of sloppy issue management. It can also be a sign that you haven't had/taken the time to evaluate those issues, which is a sign of bad project management.

Re:This is not the sad graph of software death

[Anonymous Coward]

I agree that the number of issues opened here doesn't look immediately terrible. But I disagree that this project isn't in trouble; the most noticeable problem is the dropoff in the rate of bugs being closed that started on 7-Apr, and never recovered.

Re:This is not the sad graph of software death

[Anonymous Coward]

Also, both situations are better than the created:resolved rate dropping because fewer and fewer people are using the product and therefore fewer people are running into issues. Your created:resolved rate will certainly increase each time your user base doubles, unless your product is so simple and/or formal that most of the bugs can be removed once and for all. That's sad but not bad as long as you understand what's going on.

In any case, it's not even about the number of issues. That's meaningless. It's about the experience your users have using your product. If you get a million bug reports a day because you have a billion users and all those reports are about minor things that most people wouldn't even notice, that's an excellent situation. If you get one bug a day from your one user of a severity like "your program cannot be installed" or "your program loses all state when the computer restarts due to a bug", that's very bad.

There may not even be a problem

[Anonymous Coward]

If the graph just reflects all open issues, including features, then it might actually be perfectly normal, particularly if you are just throwing everything that everyone ever asks for into the bug tracker, if there has been some kind of burst of planning activity, or if the software has just been released or tested, resulting in more issues being reported. The graph is also from a very short period, and the number of issues is quite small anyway.
The real sign of crisis won't come from graphs or metrics. How do you know what the metrics are actually telling you? Managers have to communicate with their teams and stakeholders properly to assess if there is really any kind of problem.

Technical Debt

[Henke]

At our company we have introduced the idea of Technical Debt. It allows developers to put a price tag on "bad code that needs cleaning up" and we can better prioritize that against new features with stakeholders. It's a good first step...

Re:Technical Debt

[Anonymous Coward]

At our company we have introduced the idea of Technical Debt. It allows developers to put a price tag on "bad code that needs cleaning up" and we can better prioritize that against new features with stakeholders. It's a good first step...

Yes, but how do you define a "badness metric" and price $/unit badness? Software metrics are minefields, nach lines-of code-produced PHB stupidities.

Re:Technical Debt

[Anonymous Coward]

Technical debt. Yea we did that too. The problem is technical debt does not show up in the financial quarterlies. If you were to actually take the concept of technical debt seriously, you'd need to embrace the idea through out the organization and the bottom line is that debt is debt: technical or financial it's all the same because it takes time and money to fix issues.

But it never will be put it into the financials because shareholders might realize that their shares aren't quite worth what they thought. And then - you know - the house of cards might all come tumbling down. Nobody wants that. So sorry, your so-called technical debt is managerial lip service, most likely a measure that some manager is trying to (a) marginally improve morale and (b) spearhead so as to add value to himself in the managerial food chain.

Perhaps I'm overly cynical? Perhaps. But I'm old and I've just seen this song and dance at too many companies. I honestly hope yours is different.

Get back to work!

[Hognoxious]

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:Get back to work!

[Anonymous Coward]

Taking people away from your project would cost you headcount and reduce the number of meetings you have to attend. We can't have that!!!!

Sadly, I'm watching a "scrum master" who was hired as an employee scramble to get anything done, and try to weave their way into other projects, even as the company has hired a consultant to "improve scrum". I have to take the HR guy drinking and teach him how to establish a paper trail to fire somebody, because he obviously has *no clue* about how to do it.

agreed dev time is the last to get allocated

[ILongForDarkness]

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

[Z00L00K]

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:agreed dev time is the last to get allocated

[Anonymous Coward]

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.

We have a 35 hour week (and nobody - not even a manager - works overtime). We also take seven weeks of vacation, in addition to about 10 statutory holidays. Work gets done, mostly on time and mostly within budget, and we charge well over $100 per hour. This is at a total price that Indians and Chinese can't match, even with their slave-driver mentality and limited wages. Your problems are (i) your manager, who should shield you from rapidly changing "priorities" rather than enforcing them, (ii) your time management, which seems to have far too many meetings, and (iii) those Indians and Chinese, who will outproduce you and replace you.

Re:agreed dev time is the last to get allocated

[ILongForDarkness]

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 till it is perfect but that isn't really economical. Often I'm not in a position to decide what is the best thing to work on for the customer. All I can do is figure out what is broke and what could be improved and make sure management knows my "feature" requests when considering customers/distributors feature requests.Personally I'm happy as a bit from each list gets worked on each release. Avoid worsening the rot and keep giving improvements to the customer.

Re:agreed dev time is the last to get allocated

[Z00L00K]

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:agreed dev time is the last to get allocated

[ILongForDarkness]

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 agree with you. My code reviewers however don't. They like to see a 1-1 mapping between the bug description and the work done. Also fixing code in one place vs everywhere is scene as a no-no (don't want multiple ways things are done leaking into the "design" of the software). Problem is the project gets big enough it becomes a multiple man-month job doing any refactor all the way through. If you don't do little bits while you can you have to get a manager to approve a dev doing nothing but fixes for a release which never happens in my experience (plus a lot of devs wouldn't be happy doing that).

It is also a challenge to find the existing bug to log the work against, and for the person that prioritized whatever feature you are working on to get accurate estimates given that there 3hr of work might turn into a week if you run into a lot of crap you want to fix while your at it. Dev work is challenging not only because it is, but because the people coming up with the requirements/priorities don't often look, or are able to understand, the technical challenges or specific code changes involved in the change. A customer has a phone number, vs a customer has an arbitrary number of phone numbers sounds like a simple thing. But might touch on a lot of things: business logic (what is the "main" phone number we show on the summary page?), database (now we need a join table vs a column on the customer table), tests etc.Often our work is conceptually simple but technically hard.

Even operating systems suffer from this

[Anonymous Coward]

I think even Microsoft and Apple suffer from this. Its possible Google and even the Linux distributions suffer from pushing out stuff that as we say is "half baked".
The problem I see is the marketing level controls the release dates. This happens when a company like Apple decides on a date and sticks to it, no matter if the software or OS is ready. Its clear you see it in the rapid releases of patches shortly after a major release. This really should not happen but it does because the company decides it must release not matter what to meet a deadline. My problem is, that even with software the new is not always better then the old. Since many times this is software people need to work correctly. It does seem rather obvious to ask why release something that truly is not as good in reliability as the previous version? Not to pick on Apple or Microsoft but you go to the Mac App store and look at Apple's latest software or OS (El Capitan) you will see plenty of disappointed upgraders. Also Windows 10 upgraders have expressed similar displeasure from upgrading. Not a good thing, when you push out stuff still in beta.

Let's be clear about something here

[Anonymous Coward]

The problem with graphs like this (not disputing the truth of the data) is that too often they are used to blame management rather than the source of the failure, which is a slack development atmosphere.

When projects are planned, an MRD is created and then project completion estimates flow up from the developers. The developers are committing to completion in a certain time frame. Also, the developers are the ones doing the work, including creating the bugs.

In any case, the problem here flows back to several factors, all of which lie with the devleopers:

0) Lack of sufficient skill in estimation
1) Lack of proficiency to get it right the first time
2) Lack of willingness to stick to their delivery commitments
3) Lack of upward communication when they get in over their heads
4) Sense of entitlement to more resources when they get behind

As the owner of the company, I'm not going to go out and procure additional resources to catch up on these failures, and the company has zero obligation to spend that money. Developers are responsible for obtaining the necessary skills (in both estimation and execution) to do their job function, stick to their delivery commitments no matter what it takes, and tell management when they're in over their heads. The sense of entitlement is the most disturbing part, because as an employee, your job is to work to achieve the company's goals, not your own personal goals. Also, we go to work to work, not to play. When you work for yourself, you can do that, but when you work for someone else, you are being paid to do what they ask you to do.

There's a serious lack of ownership culture in today's development society. We have to change that if we're going to avoid massive project failures like the one depicted in this graph. It costs me a fortune to bring in resources that do what I need them to do, but we don't have these kinds of project failures and we have a base of incredibly happy clients.

I don't mean to discount the disease that permeates management at most companies - that all decisions are made based on the next upcoming fiscal milestone and to appease shareholders. My directors are under strict orders to keep their eyes on the quality/time prize, and thus they have absolutely no visibility to financials, and are not paid as such. My directors' bonuses are tied only to project quality and time. My earnings are entirely based on financials, obviously, and I would like to keep my company until I retire, which requires long-term thinking on my part.

Re: Let's be clear about something here

[Anonymous Coward]

Your reply assumes that the requirements in the MRD (Master Requirements Document) are specific enough (and not totally open to changing customer interpretation) and that they are consistent (i.e., requirement 3.4.5.12.100.3 does not clash with requirement 12.23.33.4), there are no errors in the requirements, and that the requirements are achievable in a cost effective manner.

Needless to say, most MRD, especially the more complex ones, have some failings in the named areas.

Almost every project of any complexity in engineering (not limited to software) involves new information coming to light during the development phase that affects the schedule. Only very routine cookie cutter jobs can be estimated with very high accuracy.

Not just software

[Anonymous Coward]

but also hardware. That graph with the x-axis in months, not days, would be almost exact for F-16 development. In hardware, it's related to the "death spiral" where unit costs go up, causing unit sales to go down, causing unit costs go up, causing...

Infinite bugs?

[Spacelord]

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:Infinite bugs?

[notsoclever]

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.

Re:Infinite bugs?

[Anonymous Coward]

Unless it's self modifying code.

Re:Infinite bugs?

[mikael]

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 other bugs "disappear" or no longer can be reproduced.

Re:Infinite bugs?

[sysrammer]

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

platform hack workarounds

[Anonymous Coward]

Also note that older software accumulates hacks for platform problems (OS, runtime library, third-party library, you name it) which accumulates into the code base. As software keeps going, it builds up fixes, workarounds, hacks, and so on which lets it survive in the real world. As platforms evolve, you can either rewrite working code to eliminate these hacks or do new stuff. Guess which wins.

Corruption(self-serving) NOT poor communication

[nomentanus]

Everybody's talking about communication, but that's drinking the Kool-Aid, and being a good codependent.

This is the opposite of a communications problem. What the graph shows is disinvestment - it shows a clear policy that's been extremely well communicated right down to the coders. The message is: "it's working well enough, let's stop spending so much money (programmer time) and get something else done, that's now more vital." Without more context, we can't in fact rule out the possibility that this is the best business decision - although my experience is that disinvestment is frequently very premature. Investment can't be infinite, it can't keep expanding just because bug reports continue to come in at nearly the same rates (but, on average, about ever more specific and less economically damaging issues.)

I suspect (more than suspect, I've painfully experienced) that managers are often beyond ignorant about risk, but the truth is that most of their "ignorance" is pretended. Your communication skills are fine, and so are theirs. Many managers will disinvest when code is still quite dangerous because the economic rewards to them personally are large and immediate for doing so. They will build in or lock in technical and risk debt (and legal jeopardy for that matter) that can bring their whole company down to bankruptcy in full knowledge of those risks; as long as they can be reasonably sure that they will have moved on to a still better job by that time, with some bonuses tucked away that were fattened by their cheating the long-term interest of the corporation. Which they don't own. (See the Great Subprime Robbery of 2007/8.) That's corruption, of a kind very common in a "manager's economy." Maybe more common than not. It's not poor communication, and the tech field isn't immune, it attracts these managers because it's where the money is.

The reason that VCs have learned painfully to keep founders around is that founders aren't susceptible to this particular form of corruption. Founders have their payoff, now the only thing that really matters to them is how the long-term results reflect on their image. Mercenary managers are presented with very different, more perverse incentives and respond to them just as you would expect.

Re:Corruption(self-serving) NOT poor communication

[Anonymous Coward]

Interesting, do you have a citation/evidence for the fact that VCs now work to keep founders around longer? (And what mechanisms do they employ?)

Re:Corruption(self-serving) NOT poor communication

[nomentanus]

Marc Andreessen on Big Breakthrough Ideas and Courageous Entrepreneurs http://slashdot.org/comments.p... (my longer reply was swallowed.)

Re:Corruption(self-serving) NOT poor communication

[nomentanus]

And trying for the third time to see what happens in the editor now: Marc Andreessen on Big Breakthrough Ideas and Courageous Entrepreneurs https://www.youtube.com/watch?...

The lesser evil

[geophile]

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 fixed in the first round of incentives).

Alas, techies are wielding the spoons

[Anonymous Coward]

Your comment contains a good insight, but it makes an entirely unjustified followup.

I believe that you've identified the cause of the problem correctly (or at least one cause), but you're way out when it comes to apportioning blame. The main failure to understand the technology lies with the coders themselves, who most definitely think it's magic --- if they didn't, they'd realize that it's the enemy and they would keep it heavily chained. Instead, they trust it implicitly, despite a million examples worldwide every day of it failing to do what they want.

Although I'm a decades-long techie and tend to view management in this area as a bad joke, in this case non-technical management gets almost a free pass out of jail --- after all, they can't be expected to understand software. In contrast, software engineers would be expected to understand the ramifications and risks of their work 100%, and they do not.

Far from 100% understanding, it's generally not even 5%. They fail to appreciate even the most elementary concepts of risk and error rates in software. They hold a deep religious devotion to the god of It Will Just Work, and the word "religious" is chosen apppropriately because the devotion is based on faith and is unquestioned. Today's coders are not engineers, but acolytes.

Known since 1976

[Anonymous Coward]

http://www.cs.umd.edu/class/spring2005/cmsc838p/VandV/belady.pdf

Get rid of testers

[Anonymous Coward]

Get rid of testers (added process bloat) and that will hold developers more accountable for what they check in rather than them throwing shit over the cubicle fence and waiting on it to be thrown back.

AGILE SUCKS

[Anonymous Coward]

Doesn't care about good design just sprints.

Software is not about engineering

[Anonymous Coward]

Most software houses today believe software fits a factory model when in fact it is more like craft. I think this is the typical pattern: A software product is created, usually by a small, motivated group perhaps even 1, 2 or 3 people. The product ships and the team is disbanded and the product is handed over to GIT. 6 months later, nobody remains who understands how the software works. Management wants to "improve" the original product, mostly to provide a reason for charging for an upgrade. A new team is assembled. The new team cannot or is not willing to invest the painful effort to figure out how the original software worked. They return to management and say, "this software is crap", the only thing we can do is re-write it or hack it. So either the hacks begin (most common) produced by people with limited knowledge and a time horizon of 6 months or a year, or the software is re-written with a loss of features, reliability and continuity.

when you've got too many bugs...

[doom]

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 bug reports
• assume that any bugs reported before the last major release can't have anything to do with the present version

(Everything I know about software development, I learned from the Mozilla project.)

Re:when you've got too many bugs...

[Reziac]

Not coincidentally, when I looked at the graph the first thought that came to me was, "Mozilla".

Job Security

[Anonymous Coward]

Hey at least your always in demand.

Bugs from QA

[phorm]

I've found that a proper "QA" group is also pretty good at discerning bugs VS features.

Own the Problem...

[ripvlan]

or it will own you. Been there done that.

What I call the business of engineering - engineers need to think like business people. No you won't be allowed to disappear for 8 months and rewrite the product - need to keep the lights on... (plus - you created the current crap, why would you get it correct the second time?).

As others have said - use the principles of Agile. Have a clear definition of Done (Code, code review, test execution - story acceptance [tests pass & PO sign off]). This is basic 101 stuff. Plus a Clear process (use "Scrum" to enforce the good ideas). If you aren't doing this your company is behind the adoption curve. It was a new concept in 2001 - 20 years later it isn't new.

Listen to your customers. All of the little bug reports need to be grouped - New Features - per Feature, and Poor Quality (per Feature). And then own it. The business person should be able to work with you to help prioritize where investment makes sense. Where are customers complaining the most - and why? Looking at new Features should give the PO an idea of what the "Future" product needs to look like (customers do business differently as time goes on). Poor Quality - focus on distinct areas. You can't tackle it all in a single release.

Second - would a new architecture make sense? SOA/Micro is nice - but you can still create crap - you've done it before. Just that crap is isolated. Plus there's a whole new set of problems to deal with (lost or replay messages etc). But if you can make a Business case for a new architecture - then do it. And TCO can be measured (incoming bug rated decline or something like that - get your metrics defined). What are the current problems and what design changes will take care of them? Plus it helps set priorities for refactoring.

Third - any commonality to your quality issues? Figure that out and solve it. Mentor others, solve the problems, and finally - if you need it - define some process. Process will not improve quality by itself (actually process won't solve anything - you define process as the repeatable method to keep the problem solved).

Focus on each problem area - add *some* missing features, fix *some* bugs, and then move onto the next pile. Biggest impact first - make customer happy.

Listen to your customers !! Are you doing a good job? Yes - Keep going. No - "pivot"

It requires dedicated focus and commitment of everyone involved to decide it is a problem they want to solve. The company must sign up to be Agile as well - and you'll need to make the business case for why Agile is a good thing. Enlist sympathetic business people/managers. Make the story compelling.

Think like a business person.

Use the force and become a Change Agent!

Microsoft

[brunnegd]

This article describes Microsoft software, Windows, Office, etc., Get the product out the door, generate income. Let the users find the bugs on their own nickel.

Management

[whitroth]

There's far fewer problems if:
      a) management requires buy-in from the programmers
      b) management requires new scheduling and budget for enhancements and changes (other than
                    show stoppers)
      c) management puts all enhancement requests in a "next release", not "put it in, whatever it takes".
      d) management puts its money where it's mouth is, and hires a good percentage (>> 1 person) of
                    programmers with experience, and not just out of school in the last year.
      e) management is willing to say "I'm sorry, we can't, or won't do that enhancement".

                      mark

Understanding

[Anonymous Coward]

The business side doesn't respect the complexity of software development. Sets all goals, hence typically unrealistic (e.g. make a real hover board).

The engineering side doesn't respect the 3 choices of engineering: quality, time, cost (choose 2)-- by means of smoking the pipe dream of "better faster cheaper" and rapid prototyping (e.g. agile). Also engineering misses the boat of prototyping != product since all the out of the college folks (old and young) are attracted to prototyping/betas.