I nominate this author as the Fred Brooks of the 21st century. (Brooks wrote "Mythical Man Month"). These depictions of organizational sickness are spot on. I look forward to hearing more. The Carcinogenic Prototype is what Brooks might have called "the tar pit".
Symptoms of Dysfunction in Software Teams
31–40 of 56 posts
Re: Symptoms of Dysfunction in Software Teams
#32Earlier 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.
Hmm, disagree. The prototype doesn't have cancer, it causes the cancer. You're right that it's easier to say but it's saying the wrong thing.
Re: Symptoms of Dysfunction in Software Teams
#33I disagree a bit with these points. Sure, ideally you'd avoid all of these issues and having these issues several years into a product is certainly bad. But when a new product is just getting off the ground, there is a hefty cost to Doing It Right. I think many successful products would never have launched if a scary number of corners weren't cut to get version 1.0 out the door.
Depends what kind of product. If you're a start-up launching for Christmas, sure. But if it's a contract to deliver some long term custom product at a multi-year deadline (I have worked on such things), then you should definitely not push that prototype.
(Actually, the inverse error is often made: trying to get it right the first time around, which is impossible. A prototype is even worse, but least you can test your major ideas, so you can see which are good, and which are hopeless.)
Re: Symptoms of Dysfunction in Software Teams
#34Yeah... that post hit really hard. I got to quit my job or I will go crazy. Dependencies - Check Jane Doe - Check Town Hero - Hey look! It's me! Carcinogenic Prototype - Yeah sure, that's the one Jane Doe is maintaining!
The hero is negligent in their duties and intentionally leave an app is a poor state to promote their importance. Are you sure you are the hero?
yes I am. Me and all my coworkers, are actually quite good but are doing a shitty job. I'm included.
The shitty part is that they pay me above the market.
Re: Symptoms of Dysfunction in Software Teams
#35The easiest heuristic is "Are they changing ticketing systems twice per year?"
I've never seen a competent team spend any amount of time chasing after ticketing system nirvana.
Re: Symptoms of Dysfunction in Software Teams
#36I disagree a bit with these points. Sure, ideally you'd avoid all of these issues and having these issues several years into a product is certainly bad. But when a new product is just getting off the ground, there is a hefty cost to Doing It Right. I think many successful products would never have launched if a scary number of corners weren't cut to get version 1.0 out the door.
These aren't technical issues. These are issues of process and management.
I strongly doubt they have much unique to software development systems, to be honest.
Re: Symptoms of Dysfunction in Software Teams
#37The easiest heuristic is "Are they changing ticketing systems twice per year?" I've never seen a competent team spend any amount of time chasing after ticketing system nirvana.
Sounds about right.
I briefly worked at a place migrating from Trac to Jira. Oh, and they still had some stuff in Bugzilla. This team wasn't more than 2 years old.
Re: Symptoms of Dysfunction in Software Teams
#38> As with most things in software engineering the technical problems are symptoms of the economic causes.
FTFY. Seriously - #2 & #3, not enough money for a 'co pilot'. And for 2, at least there is some ostensible owner of the module, rather than a maintenance by committee which can be even shittier.
#1, maybe not cost effective to move, or would be opportunity cost. #4, I'm sympathetic to not shipping the prototype, but ever hear of first mover / time to market? obsolescence is one of the biggest risks in development[1]. Plan on shipping it and rewriting it in bite size chunks ... forever!
Anyway, it was a nice read. 'mortgage driven development' hah.
[1] In the Mythical Man Month, these are both mentioned, even though they contradict each other, and many more developers seem to only quote the 'don't ship the prototype'.
Re: Symptoms of Dysfunction in Software Teams
#39I 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?
> I am new to the industry
That's painting with a broad brush, as software is used in a huge variety of businesses. But I'd plan on any organization without mega-income-$$$ (and even that is no guarantee) being pushed to their level of competence and beyond, having turnover to deal with, having features that marketing 'needs quickly to close a big deal', and maintaining zombie ware [it wont' die]. Welcome to my 15 years of experience...
Re: Symptoms of Dysfunction in Software Teams
#40Yeah... that post hit really hard. I got to quit my job or I will go crazy. Dependencies - Check Jane Doe - Check Town Hero - Hey look! It's me! Carcinogenic Prototype - Yeah sure, that's the one Jane Doe is maintaining!
The hero is negligent in their duties and intentionally leave an app is a poor state to promote their importance. Are you sure you are the hero?
The hero is called in to patch up some flaming wreckage. Mgmt never allocates the resources to actually fix the root cause. Thus the hero is seldom at fault, otherwise they would be Jane Doe. There is a specific type of hero who deliberately creates this situation, but IME they are not the rule.
Source: I was That Guy for about 8 years at three different gigs. Now I specifically negotiate no afterhours support in my job interviews, and turn off my phone when on holiday.