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

Software development requires servant leaders

adl.io

Post reply on HN
Print view View original

91–100 of 209 posts

Re: Software development requires servant leaders

#91

Post by repolfx »

jdmichal wrote: post #29
gregoriol wrote: post #26

While overall the article is interesting, I'm really disgusted by two sentences: "In software it’s common to have something estimated at a day take a week instead." and "The inherent inaccuracy of software estimates creates extra tension that you don’t find in other industries." Oh, poor thing, you feel so special by being a software engineer? Have you never heard of construction projects taking many times the estima…

It also does not help at all that software "estimates" are typically just sticking a finger in the air and seeing how hard the wind is blowing at the moment. How many engineers are doing things like using real numbers from previous work to build models before estimating? Do we really think that every project is such a unique snowflake that we can't build models? You don't even need that much data, as long as you're u…

The conversion of estimates into commitments isn't some exception to the rule, it is the rule which is why only fools give the business estimates for things.

Also ...

Do we really think that every project is such a unique snowflake that we can't build models?

Well, yes. That's inherent to what we do. Every project IS a special snowflake. If it wasn't we'd just download the software and install it. Oddly enough, installing and configuring software that is pre-made is very predictable and such projects rarely overrun. The sort of projects we're talking about are where pre-existing software won't do and thus, by definition, what you need is something special.

Re: Software development requires servant leaders

#92

Post by [deleted] »

groby_b wrote: post #81
jonstokes wrote: post #57

This is the sort of article that makes me imagine a dialogue between a senior software engineer and a newb developer that goes something like this: Newb: Hey man, I think for this project I'll write my own SQL datastore from scratch. I've looked at a bunch of them and my project, which is basically an inventory management system, is such a special snowflake that it needs its own datastore. Senior: That would be insan…

You just might not have experienced decent leadership. Servant leadership doesn't mean you do what your reports want. It means you enable your reports to make good decisions, instead of deciding for them. It doesn't mean you don't teach, or you don't share experiences. Let me quote from the original: "The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become…

[deleted]

Re: Software development requires servant leaders

#93

Post by jbell0385 »

I experience "servant leaders" crash and burn. It's often done so poorly. They never make decisions, they just keep making vague requests for the team to come to a consensus and it's chaos. Also, another con of servant leaders is that they often don't hold people accountable. Bad behavior on the team starts to spread and moral tanks. Yes, the concepts of a servant leader sound nice, but it's often implemented horribly. Sometimes the leader needs to be aggressive, make unilateral decisions, and hold people accountable.

Re: Software development requires servant leaders

#94

Post by reciprocity »

phakding wrote: post #32

Why does software industry keep coming up with this sort of thing all the time? I worked as structural engineer before becoming software engineer and we never had to invent different kind of leadership and procedures or change office floor plans or hire outsider non-engineers as our (scrum) masters, or talk about the client as stake holders etc. Sorry about hurting your agile feelings!

It's not a bad question to ask. Structural engineering as a profession has also existed much, much longer than software development and with that comes new lessons of doing things better - perhaps at the expense of forgetting some of those problems have already been solved elsewhere.

It's as if our industry has this undercurrent of desire to reinvent the wheel instead of learning from what history is so good at teaching (providing context). No idea how on the mark I am about this.

Re: Software development requires servant leaders

#95

Post by jbell0385 »

sheepmullet wrote: post #9

Many other types of leadership can work just as well depending on the team. The biggest downside to servant leaders is, IME, they split their focus and are often not held accountable. For example if you prioritize growth as a servant leader are you held responsible if your team has a higher than average turnover? Are you rewarded if you have a lower than average turnover? Is that more important than project success t…

Exactly! I just wrote a comment like this. When I work for "servant leader" leaders, the team often lacks direction and all decisions are made very inefficiently.

Re: Software development requires servant leaders

#96

Post by vinceguidry »

Everything needs servant leadership. The whole idea of servant leadership is so unbelievably powerful that it spawned a religion that managed to convince the European world that there's a magical servant leader that was sent down to teach and serve us, and regular non-magical non-servant leaders killed him because magical leadership threatened them. People believed it, and still do to this day, because that's just the way people want to live.

A new doctrine isn't helpful. There's no new gospel to spread, the old gospel was good enough. The reason you don't see servant leadership everywhere in business is because people have different priorities and it's really hard to get them to line up. When priorities don't line up you need a class of people whose job it is to manage the disconnect and ensure that the people paying the salaries are getting what they're want, because the mismatch in priorities means they can't trust the ICs.

Servant leadership, being led by someone who has both your interests in mind, and who also thinks like you, would flatten the hierarchy so less of that ugly management business is needed. But the real answer to this dilemma, the other side of the coin of the rise of Christianity, is that you have to adapt to your masters. Christianity only became successful because they managed to become Roman, to embody Roman ideals and engage with Roman people. Only in this way could the cult of Jesus have spread so far that 400 years after its inception, it became the official creed of the Roman Empire.

A fact you miss in Sunday School.

Re: Software development requires servant leaders

#97

Post by LargeWu »

jdmichal wrote: post #29
gregoriol wrote: post #26

While overall the article is interesting, I'm really disgusted by two sentences: "In software it’s common to have something estimated at a day take a week instead." and "The inherent inaccuracy of software estimates creates extra tension that you don’t find in other industries." Oh, poor thing, you feel so special by being a software engineer? Have you never heard of construction projects taking many times the estima…

It also does not help at all that software "estimates" are typically just sticking a finger in the air and seeing how hard the wind is blowing at the moment. How many engineers are doing things like using real numbers from previous work to build models before estimating? Do we really think that every project is such a unique snowflake that we can't build models? You don't even need that much data, as long as you're u…

In my experience, PM's or whoever usually want estimates on the spot. They want estimates fast, but then they treat them as though they were well researched. If you tell them "there's a 75% probability we can get it done in 2 months" they hear "we can get it done in 2 months".

There's also a tendency to leave out important information. I recently worked on a project where 1) more than half of the features were not in the requirements because the product manager assumed we could re-use existing functionality from a completely separate application (we couldn't); 2) half of the requirements from the new work were left out of requirements because they didn't bother to specify them; 3) a critical requirement regarding how data was to be aggregated in search results (which is the primary feature) was not included because the architect didn't bother to tell anybody about it except for a passing "hey, what if we did this instead" before going on vacation. This caused 2 weeks of re-work after we were done, that would have taken 2 days if we did it from the start.

Our engineering team reviews all requirements as a team before giving estimates and this STILL happened, because we couldn't know what was missing. Good estimates begin with good requirements, and usually the people responsible for those do not end up being accountable, it ALWAYS falls on engineering.

Re: Software development requires servant leaders

#98

Post by koliber »

bluGill wrote: post #56
mightybyte wrote: post #44

Earlier quoted context omitted.

Yes, I get that all engineering (not just software) has inherent uncertainty in estimates. And there is always the chance for unanticipated events causing major overruns. But I still think that the uncertainty in software is significantly higher than in other engineering disciplines. Of course I don't have any scientific evidence for this claim. But there are lots of phenomena that exist in the world that don't yet h…

The only thing different about software is we haven't been doing it long so we don't know how to estimate. If you are writing a CRUD web app, it is just like the million others that have been written before and you should have the ability to give reasonable estimates. If you are writing a self driving car - that is new ground that only a few have attempted: there are many "unknown unknowns" that are hard to account f…

If I am developing a standard project, I will give you accurate estimates that are often correct. If I am building a custom project, my estimates will vary greatly, based on how custom it is, how well you describe what you want, and how many times I can expect you to change your mind about something.

It's really easy to tell whether you're building something standard. If it is standard, you don't need to write software for it. Say you want a standard blog. You use Wordpress. Say you want a blog that's kind of like Wordpress but a little bit different. You need to hire a programmer to write a custom component.

Effectively, all the software we write is custom. Once something becomes standardized, you no longer "build" that software. If it is standard, you install and configure it.

This is the same in the real world. If you need a standard kitchen, you can estimate how long it will take you to go IKEA, buy the cabinets, bring them home, and install it. If you want something custom, it all depends on how custom. If you want cabinets that retreat into the wall, have glass fronts, bulletproof countertops, can adjust in height so that both your 5'2" wife and her 6'11" husband can use them, in the mobile trailer that needs to tolerate temps from a dry -40F up to humid 100F without discoloration and warping, good luck. Oh, and they need to look really nice and be easy to clean. Estimate that!

TL;DR: when hiring a programmer to develop a project, nobody wants standard IKEA.

Re: Software development requires servant leaders

#99

Post by repolfx »

bluGill wrote: post #56
mightybyte wrote: post #44

Earlier quoted context omitted.

Yes, I get that all engineering (not just software) has inherent uncertainty in estimates. And there is always the chance for unanticipated events causing major overruns. But I still think that the uncertainty in software is significantly higher than in other engineering disciplines. Of course I don't have any scientific evidence for this claim. But there are lots of phenomena that exist in the world that don't yet h…

The only thing different about software is we haven't been doing it long so we don't know how to estimate. If you are writing a CRUD web app, it is just like the million others that have been written before and you should have the ability to give reasonable estimates. If you are writing a self driving car - that is new ground that only a few have attempted: there are many "unknown unknowns" that are hard to account f…

That's fine if you:

• Never upgrade your tech stack.

• Always use people of exactly the same level of skill.

• Assume the project stops at implementing a static set of requirements given up front.

• Assume the requirements are correct.

• Assume there's no political dimension to the actual deployment and usage of the app, i.e. the project is just software and not a business change project.

In practice none of these things are ever true. The business doesn't want a CRUD app, it wants an automated process that it probably can't explain, will change half way through the implementation and some of the employees may resist deployment of the software. And people expect software development to get cheaper and faster over time, as with everything else in life, so you can't exactly ship a Visual Basic 6 app in 2018 because that's what you happen to know best so you can easily estimate work with it.

Re: Software development requires servant leaders

#100

Post by JoeAltmaier »

LargeWu wrote: post #97
jdmichal wrote: post #29

Earlier quoted context omitted.

It also does not help at all that software "estimates" are typically just sticking a finger in the air and seeing how hard the wind is blowing at the moment. How many engineers are doing things like using real numbers from previous work to build models before estimating? Do we really think that every project is such a unique snowflake that we can't build models? You don't even need that much data, as long as you're u…

In my experience, PM's or whoever usually want estimates on the spot. They want estimates fast, but then they treat them as though they were well researched. If you tell them "there's a 75% probability we can get it done in 2 months" they hear "we can get it done in 2 months". There's also a tendency to leave out important information. I recently worked on a project where 1) more than half of the features were not in…

That serial approach (get good requirements; design and code; test) always works that way. An iterative approach can work better. Why isn't the architect in standup at least during the beginning of the project? All this could have been shortcut.
Post reply on HN