Avoiding traps in software development with systems thinking | Hacker News Reader

Avoiding traps in software development with systems thinking

medium.com

69 pointsnkurz11 comments

Good, lengthy read, but I find it pessimistic. Identifies well some problems, but I believe there are better strategies to mitigate the issues.

For example: http://www.theeffectiveengineer.com/blog/what-makes-a-good-e...

1. Optimize for iteration speed.

2. Push relentlessly toward automation.

3. Build the right software abstractions.

4. Develop a focus on high code quality with code reviews.

5. Maintain a respectful work environment.

6. Build shared ownership of code.

7. Invest in automated testing. ...

Author of that blog post also wrote excellent book on that subject.

All those points have the implicit premise that every problem has a technical solution. Well, except 5 which isn't so much a solution to a problem as a statement about a desirable state of affairs.

Software development seldom occurs in a vacuum and no technical solutions exist to problems that are caused by stakeholders having contradicting priorities and/or bad incentives.

Indeed. This pair of posts was more about recognising systemic patterns that are commonly seen inside and outside of software development. The examples and proposed solutions to the examples aren't the only ones or indeed probably not the best ones. The effective engineer article is very interesting.

Agreed that the biggest challenges are often non-technical. The article really hit home, especially the ‘Tragedy of the Commons”. I’m just about to leave a ‘unicorn’ startup that is beginning to implode due to team and individual sub-optimization. All directors in R&D report to the CEO and the only way to get teams to work together is with the CEO in the room. My director once said, “Why are you helping that team, if it fails, it’s their fault.” Developers are judged on commit counts and bugs fixed. No one can figure out why quality is tanking and velocity is plummeting. It’s sad to watch, like a slow motion train wreck, but it’s also a poisonous environment and no one can change it except the CEO, who blindly trusts his “Generals”, which only exacerbates the situation.

One of the things that continues to amaze me is the vast space between the simplicity of the problems groups of tech developers have and the intellectual capability they bring to the table to solve tough problems.

You could take 100 teams that are experiencing this kind of dysfunction and show each member of team an article like this. Most individual team members would easily be able to understand it. Yet in the aggregate they seem unable to do anything about it.

My guess would be: the CEO knows. He either feels unable to change anything in his specific situation or he does not care.

I've seen the infighting generals thing before, and many times behaviors like that might work in one situation but not in another.

It could be taking a lesson from somewhere else and mis-applying it. It could be he doesn't care. Also -- and this is wild -- it could be the best behavior given the circumstances and our OP just isn't aware of all of the extenuating circumstances.

Many times teams/orgs in bad situations are filled with intelligent people acting as wisely as possible, within a narrow scope. It's only at the macro level, when you add it all up, that it becomes totally whacked.

Agree with your points. There are plenty of smart people in the org all trying to do the best they can. There is a sink or swim mentality, which can be effective, but as the company grows it’s tougher to reward the swimmers and not have their work obfuscated by politicians. It’s also tough to promote cross team collaboration in this environment.

Building something from nothing is tough, and so is turning an elite team into multiple elite teams. It strikes me as the latter gets less focus in SV since it is much less frequent and goes against the entrepreneurial grain. It’s easier to bash large companies than to think about how to actually build one.

I recognize that I’m likely missing relevant factors, but some of the key problems seem to be a flat org, no VP of engineering, and no encouragement of cross team work.

When managing people, you really need to meet with more than one level below you. In a flat org, with 20 people reporting to the CEO and 40 people reporting to each of them, there is no way for the CEO to meet with all 800 people. The CEO just ends up having to blindly trust his or her direct reports that everything is good. A few bad ones can result in large sections of the company rotting from within.

Promoting cross team collaboration is tough. A company needs to emphasize this in how it promotes / rewards people and crafts the org chart. Easier said than done, but no VP of Engineering and directors promoting loyalists with no emphasis on helping other teams doesn’t help. Having multiple directors involved in promotions may help.

I like the CEO and think that he does care. He may be able to fix things, but unfortunately I don’t see it happening. I am tired of hearing everyone complain and find myself getting angry at nice people that I like due to bad incentives. My only option is to vote with my feet. He can trust his ‘Generals’ but thankfully this isn’t the military and I can leave. The grass may or may not be greener, but I’d rather take a chance on change than the status quo. Putting in my notice was an amazing relief.

> it’s also a poisonous environment and no one can change it except the CEO, who blindly trusts his “Generals”

No chance of a coup?

Software development has become a social activity. The way we organize work is all social; scrum, kanban, swarms, hackathons, etc. No real way around it these days.

"iteration speed" is the trap that leads to pushing bad code churn constantly because real thought takes time, but feeling successful anyway because you're shipping.

"automation" can be a trap that leads to band-aiding core problems; rather than figuring out why your application has so many dependencies on the operating system and makes deployment so complex, you might try to hide the mess under Docker. Now you have the original problems, plus a big dependency on a lot of complexity.

etc, etc.

Reply on news.ycombinator.com