Live data from Hacker News

Software development requires servant leaders

adl.io

131–140 of 209 posts

Re: Software development requires servant leaders

#131

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…

I can't think of another discipline like software engineering. Most other disciplines where you build things you reach a point where you deliver the product and then you're done with it, there might be some maintenance but the period of major changes is done.

In software you might have a building full of engineers working on the same product for years after it was initially delivered, adding major features, making deep changes. The level of continuos delivery doesn't exist in other fields.

Re: Software development requires servant leaders

#132

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…

A non-tech acquaintance of mine was struggling to start a cannabis business a few years ago. When he found out how much non cannabis-specific stuff went in to starting a cannabis business he lamented that he could be a successful as Bill Gates was if he only had to worry about one thing (writing software) the way Bill had.

Re: Software development requires servant leaders

#133
post #131

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…

I can't think of another discipline like software engineering. Most other disciplines where you build things you reach a point where you deliver the product and then you're done with it, there might be some maintenance but the period of major changes is done. In software you might have a building full of engineers working on the same product for years after it was initially delivered, adding major features, making de…

Sure it does. It exists in construction. You build a building to spec, and then that building is constantly outfitted for new tenants, remodeled, and renovated for decades if not centuries.

Re: Software development requires servant leaders

#134

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

You’ve setup a false dichotomy. Servant leadership can & should be decisive.

Sure maybe there's a "right way" to be a servant leader. I'm telling you how it's often executed in practice...which is poorly.

Re: Software development requires servant leaders

#135

Earlier quoted context omitted.

Structural engineers do not work primarily with other SEs. They have to collaborate with architects. Architects tend to take lot of artistic freedoms when designing a structure. We get to tell them to shove it as implementing some of their artistic designs would involve defying gravity and other laws of physics. Although that doesn't work and then you get failed/delayed/extremely over budget project SEs also work wit…

Can you show me cases where a bridge collapsed because the engineers on the project said "this will be totally unsafe" and were overruled by non-technical business managers?

https://www.usatoday.com/story/news/2018/03/16/miami-bridge-...

http://www.ejinsight.com/20180406-hk-engineers-raise-concern...

There are many more, but the fact that engineer's safety concerns were side stepped rarely sees light of the day after disaster strikes. Also it doesn't have to be a catastrophic failure. Sometimes the reduction of life span of a structure is cause of not taking care of all the concerns.

Also this does not stops with construction. Have you not heard about problems in cars or other engineering projects where safety concerns were ignored. If not, I have to ask you how old you are.

Re: Software development requires servant leaders

#136

I can't stand the phrase "servant leader". You can have a "good leader" without any other adjectives. The word "servant" is a loaded word in a way. And, has anyone heard of a "servant" that works just under the "servant leader"? Kind of a meta-slight against any group to be blessed with a "servant leader" instead of just a good one. Edit: Consider flipping the phrase, "Leader Servant". Now hopefully the silliness and…

I think (correct me if wrong) you have interpreted the phrase "servant leader" to mean "a leader of servants". Rather, it's intended meaning is "one who leads by being a servant".

Re: Software development requires servant leaders

#137

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!

Well, because we develop more value than structural engineers faster than they do and have killed far fewer people than they have. Essentially, we’re economically more efficient so a 10% improvement in our performance is huge, while a 10% improvement in structural engineer performance is a waste of time for the cost incurred. Therefore, software engineers get a lot more attention in terms of how to increase efficienc…

Sure bud! "We" developing more value (whatever that means) is equivalent to that of a stock trader on an open outcry floor thinking they develop country's economy.

Re: Software development requires servant leaders

#138

Earlier quoted context omitted.

You are referring to non-engineering managers, which will also happen in other industries, this depends more on the size of the company I'd say. Also, if you are really the only one to understand (if you are the only tech in a startup for example), then part of your job is actually to explain. Problems hit by developers are imho the same kinds that you describe with rocks: something unexpected has happened, we didn't…

They're not even necessarily referring to non-engineering managers. It's often difficult to explain to engineering managers or other engineers why something won't work or requires more work/research if they themselves have not done the work. The engineering manager isn't even necessarily that familiar with the technologies being used or experienced in the specific problem being solved. When digging a tunnel, there is…

> The upper bounds of complexity are higher in software than construction. It's not narcissism, it's just the nature of that kind of work.

It's a wonder that it works so well in fact.

I think software is probably the most complex and difficult engineering humans undertake. If you think of all the ways that a program can crash, compute incorrect results, and generally go wrong -- it's amazing that it even works at all let alone that in practice it works so well.

And we don't even have a widely accepted body of knowledge, capital-P professional obligations, liability, etc. We constantly hire people with no formal training, give them no formal training, and make no expectations of their expertise. We hire them for lots of money and put them in front of important projects and we promote them up. It's almost unreal.

Talk to a civil engineer or a doctor about what it took them to enter their profession and the amount of work they have to put in to maintain their license. And they get paid less than most software engineers.

And yet it's still somewhat unbelievable. Digging tunnels requires a lot of expertise and domain knowledge but as others have mentioned: there are only so many rocks out there to encounter. Once you have a thorough survey there are scant few unexpected problems you might run into.

But computing? Well... unless there's a battle-tested library that solves the exact problem you have then you're basically solving the problem from scratch. And one mistake is all it takes. You can't just add an extra I-beam or use a stronger steel... there's no fudge-factor in discrete systems. The whole enterprise of computing is managing complexity -- we have whole fields dedicated to the study of complexity with plenty of unsolved problems!

I believe it is just the nature of the work and why it remains so infuriatingly difficult to predict outcomes.

My pet response when someone asks why estimating software is hard: you've lost your keys in your house. give me an estimate on how long you think it will take to find them. I know you're going to think that if the keys are in the usual place it will take less than a minute. But if they're not... If you check all the places you might've been in the last few hours, maybe 5 minutes. But if they're not there then you'll have to think about how to search your whole house which could take hours. And what if you still don't find them?

And on and on.

Re: Software development requires servant leaders

#139
post #136

I can't stand the phrase "servant leader". You can have a "good leader" without any other adjectives. The word "servant" is a loaded word in a way. And, has anyone heard of a "servant" that works just under the "servant leader"? Kind of a meta-slight against any group to be blessed with a "servant leader" instead of just a good one. Edit: Consider flipping the phrase, "Leader Servant". Now hopefully the silliness and…

I think (correct me if wrong) you have interpreted the phrase "servant leader" to mean "a leader of servants". Rather, it's intended meaning is "one who leads by being a servant".

No, I interpreted the implied meaning behind the phrase, it's just as meaningless either way. "One who leads by being a servant" is a non-leader, it's an oxymoron, maybe that should have been my phrasing.

Also, it smacks of false humility. No one would call themselves a "servant leader" if they were actually a servant, they would just say "servant". Anyone who calls someone else a "servant leader" is choosing their words poorly, due to ambiguity. (what are you saying about this person if you call them a "servant leader"?) It's an absurdity, it's meaningless double-speak.

Re: Software development requires servant leaders

#140
post #131

Earlier quoted context omitted.

I can't think of another discipline like software engineering. Most other disciplines where you build things you reach a point where you deliver the product and then you're done with it, there might be some maintenance but the period of major changes is done. In software you might have a building full of engineers working on the same product for years after it was initially delivered, adding major features, making de…

Sure it does. It exists in construction. You build a building to spec, and then that building is constantly outfitted for new tenants, remodeled, and renovated for decades if not centuries.

Yeah, but the original teams that designed or built the building are long gone, and in many cases the tenant/remodel work can happen without any of the original blueprints. Buildings are meant to be modified, and this is why we have building codes, subfloors, ceiling tiles, etc. In commercial software, the startup hurdle is so great, that it usually means only a team that is contiguous with the original construction team can economically extend the original in a meaningful way.

Open source requires a different way of thinking about it; not all software can be open source. Not all buildings can be raised like a barn. In fact there is very little in the construction or civil engineering world that matches what happens in open source software.

Post reply on HN