Symptoms of Dysfunction in Software Teams

<i>It was a neat prototype, you know. A few loose ends here and there, but a solid proof of concept. Executives loved it. Could see the $_$ in their eyes. So they had us plug the holes and get it to production as fast as possible. Time to market, that sort of things. I recall John didn&#x27;t like it. Caused quite a stir. But who was he to decide anyway?</i><p>[…]<p><i>Yeah, that became quite the thing. Lots of new features. Funny thing is, they used to come fast. Not so much lately. Did ask why —were simple features—, but all I got was some bullshit about about &quot;technical debt&quot;. Don&#x27;t give a crap is what they do. No matter, we&#x27;re entering cash cow mode now. Champaign?</i><p>[…]<p><i>I&#x27;d like to, but John left (something about a &quot;big ball of mud&quot;), and Bob got promoted… That leaves Jane and Sally. Still many glitches to fix, but they will do —not like I have a choice. Besides, they know the billing subsystem inside out, and women are good at cleaning things up, right? Wait, I didn&#x27;t —are you recording this?</i><p>[…]<p><i>Phew, that was a close call. Jane warned IT about that OS update, but they kept talking about this &quot;security update&quot;. Four days without revenue! Jane and Sally were no good, even Bob couldn&#x27;t see what was wrong. Had to call John back, you know. Fixed the problem in a pinch. I hear HR made an offer, but I guess there was no changing his mind. Oh well, at least things are back to normal.</i><p>[…]<p><i>Dunno why, but this systems scares me a little bit.</i>

I 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&#x27;d like the prototype so much they&#x27;d come back with a completely unrealistic deadline for the finished product.<p>They did. They wanted it ready in 3 months. I estimated 10.<p>We delivered something - I&#x27;d hesitate to call it a finished product - 15 months later, and it was deservedly panned by users.<p>I&#x27;ve spent a lot of time since pondering exactly where it all started to go wrong, and I&#x27;m entirely convinced the day we demonstrated the prototype was it.

The &#x27;it depends&#x27; answers are good and I would not cite them as evidence of a problem. You employee people who understand what they are talking about and who also understand the importance of an accurate answer. They are probably very good engineers.<p>How does X close a TCP connection... it depends on the operating system in question. What cipher does my browser use when talking to X website... it depends on what ciphers are supported&#x2F;available and how the client&#x2F;server are configured. Which router do these packets go through... it depends. Is my password secure... it depends on the string you chose, the hash type used to store the password and who the attacker is and what their resources and time frames are.<p>There is hardly anything absolute in technology&#x2F;software. And, people who want an absolute answer are only indicating that they do not understand the fundamental complexity issues that we deal with as technologists.

I once worked with a guy who gave a lot of &quot;it depends&quot; answers. (In fairness, he was the chief scientist, and there was a lot more of valid &quot;it depends&quot; than I wanted to recognize in the way microwaves interact with living tissue.)<p>One day a coworker and I asked him a question, and demanded that he give us a yes or no answer. He thought for a moment, and then replied: &quot;Yes. However...&quot;<p>[Edit: Fixed typo.]

I&#x27;ve been stuck maintaining a carcinogenic prototype for the last 2 months. While I don&#x27;t like dealing with the maintenance nightmare, I do really like that term. I&#x27;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.

The easiest heuristic is &quot;Are they changing ticketing systems twice per year?&quot;<p>I&#x27;ve never seen a competent team spend any amount of time chasing after ticketing system nirvana.

I disagree a bit with these points. Sure, ideally you&#x27;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&#x27;t cut to get version 1.0 out the door.

Yeah... that post hit really hard. I got to quit my job or I will go crazy.<p>Dependencies - Check<p>Jane Doe - Check<p>Town Hero - Hey look! It&#x27;s me!<p>Carcinogenic Prototype - Yeah sure, that&#x27;s the one Jane Doe is maintaining!

I 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?

&gt; As with most things in software engineering the technical problems are symptoms of the <i>economic</i> causes.<p>FTFY. Seriously - #2 &amp; #3, not enough money for a &#x27;co pilot&#x27;. And for 2, at least there is <i>some</i> ostensible owner of the module, rather than a maintenance by committee which can be even shittier.<p>#1, maybe not cost effective to move, or would be opportunity cost. #4, I&#x27;m sympathetic to not shipping the prototype, but ever hear of first mover &#x2F; 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!<p>Anyway, it was a nice read. &#x27;mortgage driven development&#x27; hah.<p>[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 &#x27;don&#x27;t ship the prototype&#x27;.

I nominate this author as the Fred Brooks of the 21st century. (Brooks wrote &quot;Mythical Man Month&quot;). These depictions of organizational sickness are spot on. I look forward to hearing more. The Carcinogenic Prototype is what Brooks might have called &quot;the tar pit&quot;.