Live data from Hacker News

Heisenberg Developers (2014)

mikehadlow.blogspot.cl

101–110 of 193 posts

Re: Heisenberg Developers (2014)

#101
This is one of the best posts on software development I've read in many years. Each sentence rings true and is an amazing read.

Its like the author is describing many of the projects I've worked before.

Micromanagement and software factories are the death of software development.

But then no matter how much I dislike these management methods, I can see why they are put in place.

There are certain developers that get to a project and just start rewriting everything with no good reason, introducing new cutting edge tools and frameworks for the fun of it and for pure CV driven development.

They introduce huge bugs close to release dates, breaking browser support, refusing to test on IE.

Lets face it, loose canons exist on all teams and we've all seen it before.

This is OK and necessary in the early development cycle, but when things get to production its different. One day something gets seriously broken, and management comes in putting in JIRA or equivalent, and micromanagement starts.

Demotivation of the early developers sets in, the ones who knew how to setup an architecture and make technical decisions. The leave and are replaced by other developers that don't necessarily could take those decisions.

The project entered a pure maintenance phase, where business as sort of given up asking too many features, it just costs too much and the results are less than ideal.

The project enters the keep it running final phase, where noone knows how certain parts of the system work anymore, all original developers long gone. Here the goal is to touch the code as least as possible and its no longer a development job, its mostly technical analysis and troubleshooting of test environments.

Then 5 or 7 years have gone through, and the business decides to replace the system with a new one and the cycle starts again.

The only way i've found to deal with this, is to become a contractor and work mostly on early to mid phases of projects. When the project enters pure maintenance I wait for a few months and then look for a new project.

Re: Heisenberg Developers (2014)

#102
post #92

Ever work with an engineering team? Building new weapons systems? Fighter planes and the like? Just as creative an endeavor if not more so than software development yet they have schedules and budgets to meet too. And yet people's lives depend on the result. Software development can learn a lot from other engineering disciplines.

I feel like you might have missed the point. Also you're assuming these engineering teams for weapons systems and fighter planes are successful by default.

F-35?

Re: Heisenberg Developers (2014)

#103
post #2

This is exactly where my job is headed. We hired a project manager who frankly knows nothing about tech. Suddenly, we the developers are no longer able to file tickets ourselves and the tickets themselves need to be blessed and have specs the higher ups can approve. One liner for a hot fix that's filling the error logs? Needs a ticket - a ticket we can't file. All pull requests need one or more associated tickets. I'…

Every time I read something like this (because experiencing is just to traumatic to remember) I tend to share http://algeri-wong.com/yishan/engineering-management.html

One day I hope to find some place small that applies that by the 'book'.

My personal anecdote was, that no matter how much I tried to persuade the PM that it's a bad idea to put all the platforms (iOS, Web, Android, etc) stories and bugs into one giant tracker (Pivotal Tracker) we ended up doing that.... until the sudden realisation that it's a bad idea. It's hard to believe that PM had been on software projects before.

Found a typo in what is otherwise awesome writing, "loosing".

Re: Heisenberg Developers (2014)

#104

Earlier quoted context omitted.

You're right, sounds like maybe a bit of over-generalization from your situation :) Do you have a direct manager who talks with you about your career growth? A good one might help you find projects that engage your broader interests. There are certainly roles and projects that involve some degree of inter disciplinary work, and not just at founder or team lead levels. If not at your company, there are certainly some…

I was always interested in technical PM roles, but I'm best at full-stack development. The most important work criteria for me, is to see the business as something I'd invest in. If I think the product matters (can have a serious positive impact on it's customers, rather than a marginal one), it's easy to get excited about it. I have a few dev managers and experienced engineers who I've kept in contact with from an o…

I feel the same way, it's hard to care about something you wouldn't use or evangelise about, unless it's deeply niche and complicated enough to go over my head and make me feel dumb.

Re: Heisenberg Developers (2014)

#105
post #32

Not 100% convinced by the conclusion. There is good project management which can be relatively fine grained, but it doesn't have to be micromanagement and it doesn't have to be a death march. There are some basic red flags raised: > Our project manager would be displeased when tasks took longer than the estimate and would immediately assign one of the other team members to work with the original developer to hurry it…

> Shouldn't happen just at the whim of the PM. A sane environment would work by a developer asking for help first, and it actually sounds odd that you have capacity for a PM to throw someone to just 'hurry up' tasks

The problem is that if the PM decides to do that, the developer has no authority to refuse that.

> Any PM who says features are set in stone isn't doing their job. A PM's role is to handle change and execute the plan. Sounds like weak management.

Most PMs are just proxies for business, they manage up and out but not down. They will not risk their jobs by refusing requests from business, in the long term that would put them in an unsustainable position.

Re: Heisenberg Developers (2014)

#106

Earlier quoted context omitted.

> The company is bigger than you are, its decisions weigh heavier than yours. Stop with the ego-belief that you know better than it. You sound just like a church. Friction is good, differences in opinions and priorities are good. Especially in a creative environment. When a part of that is silenced based on just organisational/hierarchical arguments, everyone involved will become less effective in one way or another.…

> Especially in a creative environment. It is not a creative environment. We are talking about mid- to big-sized projects and companies here. Not the scrappy startup, not the open source consultant shop, not the small niche application for your Macbook. Differences in opinions are good, provided the team as a whole is reasonably aligned. Too much divergence and this "room for creativity" becomes a schizophrenic organ…

Did the development team in this example become more or less productive after it became "reasonably aligned"?

Re: Heisenberg Developers (2014)

#107

Earlier quoted context omitted.

How do you feel about the potential for high turnover with entrepreneurial types, as it seems the general consensus is they will inevitably leave to start their own thing? How long do you expect someone to work for you before hiring them, getting them up to speed with your system, and integrating them into the company is a worthwhile investment?

When I get asked this in an interview, I always answer the same way: yes, I will probably go to the next gig faster than other employees. But I will get up to speed faster, and I will produce more output for the business itself in the time I'll spend in your company.

This is the reality but my question was more about perception vs reality.

Re: Heisenberg Developers (2014)

#108

The more projects that I've shipped from conception to completion, the more I'm believing that there are two fundamental phases for each project, and you need radically different management philosophies for each. Phase 1 is "will it work?" You get a vaguely-specified business requirement, maybe some intuition that a market could be better served by software. And your job is to build that software, and figure out exac…

The more projects I work on the more I am convinced most projects are a combination of phase 1 and phase 2 work.

The biggest problem I see is projects usually adopt a one sized fits all approach.

If part of the team is using a strict scrum process and they find it helpful because they are doing phase 2 work then all of the team gets forced into it even if they are doing phase 1 work etc.

Re: Heisenberg Developers (2014)

#109

Earlier quoted context omitted.

You're right, sounds like maybe a bit of over-generalization from your situation :) Do you have a direct manager who talks with you about your career growth? A good one might help you find projects that engage your broader interests. There are certainly roles and projects that involve some degree of inter disciplinary work, and not just at founder or team lead levels. If not at your company, there are certainly some…

I was always interested in technical PM roles, but I'm best at full-stack development. The most important work criteria for me, is to see the business as something I'd invest in. If I think the product matters (can have a serious positive impact on it's customers, rather than a marginal one), it's easy to get excited about it. I have a few dev managers and experienced engineers who I've kept in contact with from an o…

Well it looks like you got a positive signal from Instacart :) Good luck with the hunt.

Re: Heisenberg Developers (2014)

#110

This is one of those wishful thinking rants that serves to highlight the rose-colored glasses many developers see the business world through. All good things eventually come to an end, and you need to be ready for the inevitable. The author described two perfectly good responses for this scenario, and managed to paint them both as the cowards path. Leaving the company, and checking out mentally, letting the people wi…

Sure rose-colored glasses is a part of it. But at the same time, you have them too. The problem here is lack of leadership and the organization is trying to solve it with management. The parable of the loggers is apt in the authors situation. > A group of loggers is busy chopping away doing great work under the supervision of the managers and achieving high productivity and throughput. Someone from a mountain overloo…

> The problem here is lack of leadership and the organization is trying to solve it with management.

Management is a resource that can be easily added or subtracted from an organization, leadership is not. Good leaders are rare, but management can be taught.

Post reply on HN