Symptoms of Dysfunction in Software Teams
blog.hedges.net
Symptoms of Dysfunction in Software Teams
1–10 of 56 posts
Re: Symptoms of Dysfunction in Software Teams
#2I've been stuck maintaining a carcinogenic prototype for the last 2 months. While I don't like dealing with the maintenance nightmare, I do really like that term. I'd never heard it before, but I knew what it was as soon as I read it -- the text in that section only confirmed my suspicion.
Re: Symptoms of Dysfunction in Software Teams
#3I've been stuck maintaining a carcinogenic prototype for the last 2 months. While I don't like dealing with the maintenance nightmare, I do really like that term. I'd never heard it before, but I knew what it was as soon as I read it -- the text in that section only confirmed my suspicion.
Yeah, this definitely feels like a permanent addition to the lexicon. It crisply describes at least two systems I'm maintaining currently.
Re: Symptoms of Dysfunction in Software Teams
#4I've been stuck maintaining a carcinogenic prototype for the last 2 months. While I don't like dealing with the maintenance nightmare, I do really like that term. I'd never heard it before, but I knew what it was as soon as I read it -- the text in that section only confirmed my suspicion.
Yeah, this definitely feels like a permanent addition to the lexicon. It crisply describes at least two systems I'm maintaining currently.
If it gets canonized, I'd much prefer "cancerous prototype" because it's easier to say.
Re: Symptoms of Dysfunction in Software Teams
#5I am new to the industry and have only really had limited experience. Is it more fair to call these symptoms of dysfunction or business as usual. How do you begin to avoid these problems?
Re: Symptoms of Dysfunction in Software Teams
#6Re: Symptoms of Dysfunction in Software Teams
#7I was on a project that produced a carcinogenic prototype. The irony was we knew it at the time. Before it was shown to the higher-ups, us developers joked that they'd like the prototype so much they'd come back with a completely unrealistic deadline for the finished product.
They did. They wanted it ready in 3 months. I estimated 10.
We delivered something - I'd hesitate to call it a finished product - 15 months later, and it was deservedly panned by users.
I've spent a lot of time since pondering exactly where it all started to go wrong, and I'm entirely convinced the day we demonstrated the prototype was it.
Re: Symptoms of Dysfunction in Software Teams
#8Earlier quoted context omitted.
Yeah, this definitely feels like a permanent addition to the lexicon. It crisply describes at least two systems I'm maintaining currently.
If it gets canonized, I'd much prefer "cancerous prototype" because it's easier to say.
I like this better too - the prototype will inevitably grow from its humble origins, and with every new feature that is hastily thrown in, the application becomes ever so much riskier.
Re: Symptoms of Dysfunction in Software Teams
#9I am new to the industry and have only really had limited experience. Is it more fair to call these symptoms of dysfunction or business as usual. How do you begin to avoid these problems?
In my experience, one easy way to determine how good the job is going to be is based on the pecking order of various departments in the company. At a company that does software, the software developers are usually at or near the top. Alternatively, at a marketing company, the marketers are at the top and the software developers may very well be near the bottom.
You can gather this information in a number of ways in an interview. Simply ask one of the interviewers where their group exists in the company hierarchy. If you don't want to be explicit, ask to look at the area where the developers sit and work. If the area is well done and people seem happy, you're probably in good shape. If the people are essentially stuffed into a closet or makeshift office/hallway then you might want to run.
Generally, try to work for a company that makes money on software or technology. A company that makes money on other products or services is likely to treat software developers as a low-level function of the organization.
Re: Symptoms of Dysfunction in Software Teams
#10I am new to the industry and have only really had limited experience. Is it more fair to call these symptoms of dysfunction or business as usual. How do you begin to avoid these problems?
It's easy to say this is a large company problem, but I've seen serious technical debt issues at companies that are less than a year old.
The easiest way to avoid these problems is to commit to clean code, and having the stones to stick to that plan. That means someone in power needs to agree with this way of doing things.
In my experience, the tone of a company is set from the top and works down. If the boss is non-technical and is not open to delegating, then there is nothing that can save that company other than new leadership.