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

Maximizing Developer Effectiveness

martinfowler.com

Post reply on HN
Print view View original

91–100 of 168 posts

Re: Maximizing Developer Effectiveness

#91

Post by choeger »

Did anyone else notice that there is no software engineering management involved in the "ideal" picture? In this ideology, every developer acts autonomously, even by deploying to production. This removed all technical responsibilities from the well-payed management people. Conflicts? Resource management? Scheduling? Happens to other people. At the core of this ideology lies the principle that every software is just a bag of fully orthogonal features that can be implemented completely independent of each other and will play nicely together. If this assumption does not hold, it's the developer's fault (aka "ownership").

Dear developer colleagues, do not fall for this trap. Hold your managers responsible. Let them make the difficult decisions. Real leadership should lift some burden from the people being lead.

Re: Maximizing Developer Effectiveness

#92

Post by Ma8ee »

cjfd wrote: post #81
lxe wrote: post #51

Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel un…

It is true that the effective developer environment sounds a bit too good to be true. Also, there seems to be a contradiction in it. We get an answer from the other team very quickly but on the other hand there are no interruptions. It seems a bit hard for both of these things to be true at the same time. On the other hand one does have to notice that one can either be moving towards the effective developer environme…

And how do you resolve this contradiction? Teach your employees that if you don’t want to be interrupted you better write good documentation. And have one dedicated team member each day responsible for supporting other teams. I think both of those are mentioned in the article, but it was a little a while since I read it.

Re: Maximizing Developer Effectiveness

#93

Post by leghifla »

Ma8ee wrote: post #92
cjfd wrote: post #81

Earlier quoted context omitted.

It is true that the effective developer environment sounds a bit too good to be true. Also, there seems to be a contradiction in it. We get an answer from the other team very quickly but on the other hand there are no interruptions. It seems a bit hard for both of these things to be true at the same time. On the other hand one does have to notice that one can either be moving towards the effective developer environme…

And how do you resolve this contradiction? Teach your employees that if you don’t want to be interrupted you better write good documentation. And have one dedicated team member each day responsible for supporting other teams. I think both of those are mentioned in the article, but it was a little a while since I read it.

"Teach your employees that if you don’t want to be interrupted you better write good documentation."

And reward them for doing it.

If your company do "360 degree" evaluations where your peers praise you for your quick answers to their questions, you are effectively incentivised to NOT document and instead be interrupted...

Re: Maximizing Developer Effectiveness

#94

Post by daniel-grigg »

vasco wrote: post #77
postit wrote: post #61

Earlier quoted context omitted.

Thanks. This summarizes and completes perfectly the ThoughWorker bingo. They are always dreaming about the ultimate factory line for knowledge workers, but they don’t get much done other than blog posts.

I don't know about what they actually do because I've never interacted with the company other than reading what they publish. I have to tell you that if you apply the things they share, where previously you had a home-grown "process" or lack thereof, your engineering organization will produce better results and your engineers will be happier. I can't vouch for every single thing they ever wrote, but I think this styl…

The pendulum can swing too far both ways. Having worked for a startup that consisted of probably half ex-thought workers I can attest that yes some of the development processes and infrastructure we created were commendable. Some others were just absolutely frustrating. However I feel the only metric that’s really worth mentioning is that after a couple of years, there was practically no product to show of, not a single paying customer and the company slowly burned through its entire runway and faded to (more) obscurity. Yes I’m convinced that the ideological stances such staff took were directly correlated with the business failure. I think the only positive result was focusing on building an ivory tower meant everyone’s CV looked more impressive.

Re: Maximizing Developer Effectiveness

#95

Post by leghifla »

I am the first to ask for quick feedback loops, which makes the dev environment so much enjoyable. But I have also seen some detrimental long term effect of this.

I have seen developpers "coding to the test". By that I mean they are modifying a piece of code they do not know well, and assume that if test pass, that must be good. Without understanding that test will never cover all possible inputs/states of the system. This "coding to the test" can appear very fast with a quick feedback loop, making possible to "monkey code" something until it passes. If you do not have careful review, by people knowing the system, this will end badly, with race conditions only appearing in production, integration failing randomly.

Re: Maximizing Developer Effectiveness

#96

Post by UK-Al05 »

choeger wrote: post #91

Did anyone else notice that there is no software engineering management involved in the "ideal" picture? In this ideology, every developer acts autonomously, even by deploying to production. This removed all technical responsibilities from the well-payed management people. Conflicts? Resource management? Scheduling? Happens to other people. At the core of this ideology lies the principle that every software is just a…

I'm presuming in this ideal land, the stories are already ordered in the most optimal way. So no scheduling conflict.

Resource and release conflicts don't appear if you have the right infrastructure.

Re: Maximizing Developer Effectiveness

#97

Post by joana035 »

onethought wrote: post #65
postit wrote: post #61

Earlier quoted context omitted.

Thanks. This summarizes and completes perfectly the ThoughWorker bingo. They are always dreaming about the ultimate factory line for knowledge workers, but they don’t get much done other than blog posts.

Even by the HNs/SV measure of success they just got 700 million in funding and a 4.6 billion valuation... Just from writing blog posts apparently.

Well, sell each consultant hour ~100 and pay ~30. After the initial project implementation swap the whole team to India, move the existing people to another projects. Keep everyone in a cult like mindset, profit.

Re: Maximizing Developer Effectiveness

#98

Post by cjfd »

Ma8ee wrote: post #92
cjfd wrote: post #81

Earlier quoted context omitted.

It is true that the effective developer environment sounds a bit too good to be true. Also, there seems to be a contradiction in it. We get an answer from the other team very quickly but on the other hand there are no interruptions. It seems a bit hard for both of these things to be true at the same time. On the other hand one does have to notice that one can either be moving towards the effective developer environme…

And how do you resolve this contradiction? Teach your employees that if you don’t want to be interrupted you better write good documentation. And have one dedicated team member each day responsible for supporting other teams. I think both of those are mentioned in the article, but it was a little a while since I read it.

I would be inclined to say that interruptions to help your colleagues should be accepted. Writing good documentation is actually hard and if you not willing to invest the time to do it well and to make sure the documentation can be found when needed you had better not write documentation at all.

Re: Maximizing Developer Effectiveness

#99

Post by ownagefool »

cjfd wrote: post #81
lxe wrote: post #51

Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel un…

It is true that the effective developer environment sounds a bit too good to be true. Also, there seems to be a contradiction in it. We get an answer from the other team very quickly but on the other hand there are no interruptions. It seems a bit hard for both of these things to be true at the same time. On the other hand one does have to notice that one can either be moving towards the effective developer environme…

The article specifically suggests there's a dedicated support developer, which means you're sacrficing one member of your squad (per week) for the productivity of the rest of them. We can debate whether the idea is good or bad, but it's not pretending that its magic.

On the wider article, I think the litrature is a poor subsitutde for reality. And honestly I question whether a lot of these agile consultancies actually have the required experience to teach us how to be highly effective as opposed to what we can learn directly from orginsations that are highly effective, but I do believe they have enough experience to tell us that effective development teams invest in development tooling, dev focused user experience, and a dev focused culture.

Who and how you'll build this is left as an excercise for the reader, which is unfortunte because we now have a legion of consultants who've never produced a line of code making a career telling us "culture is hard" and then forcing us into scaled agile frameworks and tooling that are contradictory to the ethos.

Doesn't mean the underlying point is bad though. Engineering teams need some time to work on developer experience instead of just being feature factories; bigger org can hire teams dedicated to helping with this. This is a good thing, but many orgs fail at understanding and allowing the investment.

Re: Maximizing Developer Effectiveness

#100

Post by BossingAround »

FlyingSnake wrote: post #80
lxe wrote: post #51

Here I am, a productive developer eager to deliver maximum value to my customers and apply my innovation to company goals. Open up JIRA and pick up a unit of work to produce today -- gotta stay faithful to those story points! Somehow, a magic team of spherical devops in a vacuum created an environment where things are just green, predictable, and are never broken. Another theoretical team of angels from a parallel un…

This reminds me of this wonderful piece of art from Krazam; The Hustle. [1]: https://m.youtube.com/watch?v=_o7qjN3KF8U

His microservice video [1] is also pretty awesome!

[1] https://www.youtube.com/watch?v=y8OnoxKotPQ

Post reply on HN