Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Symptoms of Dysfunction in Software Teams

blog.hedges.net

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Symptoms of Dysfunction in Software Teams

#41

Post by a3n »

thu wrote: post #18
ef47d35620c1 wrote: post #13

The 'it depends' 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. 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 ciphe…

That didn't seem his point. He didn't say at all that the person providing the answer was not competent or being imprecise or whatever negative. The example he gave was different that yours: it was about the software the team is responsible for and about the fact that technical debt has been formed. In dysfunctional organizations, dysfunctional software happens despite of the bright people.

"In dysfunctional organizations, dysfunctional software happens despite of the bright people."

A variation of Conway's law. https://en.wikipedia.org/wiki/Conways_Law

Re: Symptoms of Dysfunction in Software Teams

#42

Post by groovy2shoes »

logicalmind wrote: post #9
krisdol wrote: post #5

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?

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 a…

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

I'd say this is usually good advice, but with a caveat: larger companies with deep chains of command -- even software companies -- typically have "management culture". These types of companies put a lot of pressure on their employees to move into management, even if they're not good at it or they don't want to. These companies reward playing social power games above any other kind of achievement. There will be lots of meetings and not a lot of work being done. There will be no reward for technological innovation or productivity.

So, I'd say avoid companies with deep management hierarchies unless 1) you want to go into management or 2) are stoked by the thought of doing the bare minimum.

Re: Symptoms of Dysfunction in Software Teams

#43

Post by zachrose »

a3n wrote: post #41
thu wrote: post #18

Earlier quoted context omitted.

That didn't seem his point. He didn't say at all that the person providing the answer was not competent or being imprecise or whatever negative. The example he gave was different that yours: it was about the software the team is responsible for and about the fact that technical debt has been formed. In dysfunctional organizations, dysfunctional software happens despite of the bright people.

"In dysfunctional organizations, dysfunctional software happens despite of the bright people." A variation of Conway's law. https://en.wikipedia.org/wiki/Conways_Law

The potential corollary: "In functional organizations, functional software happens even when the people aren't that bright."

Exciting or sad, or both?

Re: Symptoms of Dysfunction in Software Teams

#44

Post by quanticle »

zachrose wrote: post #43
a3n wrote: post #41

Earlier quoted context omitted.

"In dysfunctional organizations, dysfunctional software happens despite of the bright people." A variation of Conway's law. https://en.wikipedia.org/wiki/Conways_Law

The potential corollary: "In functional organizations, functional software happens even when the people aren't that bright." Exciting or sad, or both?

>"In functional organizations, functional software happens even when the people aren't that bright."

It could happen, but I've never seen it, nor have I even read about it the literature. The sum conclusion of 20 years of software engineering literature is that two things matter: the quality of your programmers and the stability of your requirements. Of those two, the first matters more than the second. Get those two, and it doesn't matter what methodology you use, you'll have functional and elegant software. Miss those two, and it doesn't matter what methodology you use, your software will be crap.

Re: Symptoms of Dysfunction in Software Teams

#45

Post by a3n »

quanticle wrote: post #44
zachrose wrote: post #43

Earlier quoted context omitted.

The potential corollary: "In functional organizations, functional software happens even when the people aren't that bright." Exciting or sad, or both?

>"In functional organizations, functional software happens even when the people aren't that bright." It could happen, but I've never seen it, nor have I even read about it the literature. The sum conclusion of 20 years of software engineering literature is that two things matter: the quality of your programmers and the stability of your requirements. Of those two, the first matters more than the second. Get those two…

> the quality of your programmers and the stability of your requirements. ... Get those two, and it doesn't matter what methodology you use, you'll have functional and elegant software.

I've always believed that when excellent programmers advocate whatever methodology they use (e.g. Beck et al.) they themselves are missing the fundamental fact that they could produce excellent software using three sea shells.

I'm really glad that those excellent and public programmers don't have a more perverse sense of humor.

... or, maybe they do ...

Re: Symptoms of Dysfunction in Software Teams

#46

Post by bananas »

alrs wrote: post #35

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

Agree. The last company I worked for used salesforce, email and excel to manage a 1 million line enterprise behemoth. Without much hesitation as I was employed to fix the company, with zero budget we fired up trac and integrated it with AD and their reporting stuff. Now this was frowned upon (open source!?!?! Never!) but it delivered real results and traceability. Now a year down the line and 5000 tickets later they finally accepted the value and assigned a PM to look at the company processes which were clearly broken.

A month later a totally broken copy of JIRA appeared whilst I was on holiday with the old process that was broken crudely crammed into it with no reporting, no backup/restore and no amount of crazy spared. Yep clearly the problem was the issue tracker not the process.

Now $32000 a year in protection money from Atlassian hits the upper management team (as well as the process brick wall which bottlenecks everything on the PM) so they decided that the problem is:

"We need another ticketing system. Sales force is looking good if we can just customise it for our process."

So I quit with much "fuuuuuuuu..."

Re: Symptoms of Dysfunction in Software Teams

#47

Post by vinceguidry »

logicalmind wrote: post #9
krisdol wrote: post #5

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?

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 a…

This isn't necessarily true. I'm the one-man maintainer of the makeup company I work for's Rails site. It's a pretty sweet gig. The marketing team's turnaround doesn't even come close to mine, so I get a lot of downtime from adding new features. They literally can't think of things to implement faster than it takes for me to do them.

There's a lot of technical debt, but I have the time to clean it up. Most of the previous guys in my job just coasted, so I'm already kicking ass compared to them.

Re: Symptoms of Dysfunction in Software Teams

#48

Post by ak39 »

loup-vaillant wrote: post #33
crazy1van wrote: post #25

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

I think the "prototype" analogue borrowed from engineering to software is a bit problematic. I don't believe there is such a thing as a "working prototype" in software. It either works or it doesn't. If it works and that's what business needs in the production environment, then ship it already. Nothing wrong with that.

The problems start arising when the issues of scalability and maintenance were not considered part of the prototype development. And this problem does not only affect "carcinogenic prototypes" [sic] ... such problems manifest, and do so regularly, with software projects that had multi-year deadlines and good intentions all-round vis-à-vis scalability and easy maintenance.

Re: Symptoms of Dysfunction in Software Teams

#49

Post by ak39 »

vinceguidry wrote: post #47
logicalmind wrote: post #9

Earlier quoted context omitted.

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 a…

This isn't necessarily true. I'm the one-man maintainer of the makeup company I work for's Rails site. It's a pretty sweet gig. The marketing team's turnaround doesn't even come close to mine, so I get a lot of downtime from adding new features. They literally can't think of things to implement faster than it takes for me to do them. There's a lot of technical debt, but I have the time to clean it up. Most of the pre…

That's the thing: technical debt is the cost of innovation.

Edit: "Technical debt has to be the acceptable cost of rapid and affordable innovation."

We can't talk about (technical) debt without recognising the commensurate leverage it provides to business. If a debt does not continue leveraging the business, then and only then, can it be considered carcinogenic. And the only reliable solution then is to simply switch the solution off or replace it.

Re: Symptoms of Dysfunction in Software Teams

#50

Post by bermanoid »

iMark wrote: post #7

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'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 lat…

Not at all - the day you went wrong was the day you wrote code that worked and assumed that the people paying you would let you rewrite it later.

That never happens, unless you force the issue by making the first version fundamentally unsalvageable through choice of language or something like that.

If you don't know for sure that you can't (for a very real reason, like the fact that AS3 won't run on iOS) ship a line of code, it's on you to assume that everything you write is going to get to production. That's the reality, even if it's uncomfortable.

...I say as the lead on a game that just got sent in for review today, 8 months early, with 95% of the "prototype" code that we started a few months ago intact. Luckily we never believed that it was actually prototype code, because wasting a month and a half to recreate something that already works is a hard sell to anyone that hasn't struggled with the codebase already.

Pad estimates, and plan for the worst, is all I can suggest. But also realize that sometimes short timelines are a blessing: the people that would be filling up the feature request list stop doing so once you tell them that you're already overcommitted by 80%. That helps the product, usually.

Post reply on HN