Given that people move jobs quickly anyway, it is not clear that value matters. Rather, I need the appearance of value by X and if that is done by mortgaging the future, well, that is the next guy's problem.
That's a problem, not a solution.
Driving engineers to an arbitrary date is a value destroying mistake (2020)
151–160 of 208 posts
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#152Earlier quoted context omitted.
You worked on that app yourself alone, right? If so, I believe your app belongs to a different plane of existence. Programming (one programmer working alone without too much money/time pressure imposed by others) is quiet different from software engineering (multiple programmers, stakeholders, designers, etc., with time and money constraints). Everyone loves programming (and so doing programming usually leads to high…
I would say a lot of this confusion comes from the word engineer. Building software is not like building a bridge. You can't design it first and then go and build it. So I would say engineer is a poor term, but also the only one we've got for now.
No it's not like building a bridge. It's like thinking you're building a bridge but then the client decides he needs it to be moveable so then you have to give it legs so it can walk. Then the client's manager decides he wants it to be able to get to the moon so you then have to strap rockets and parachutes to it. Then after it gets installed and someone finally speaks to the users you realise all they needed was a canoe.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#153Given that people move jobs quickly anyway, it is not clear that value matters. Rather, I need the appearance of value by X and if that is done by mortgaging the future, well, that is the next guy's problem.
That's a problem, not a solution.
I agree that it is a problem. I just think the root cause here is driven heavily by how careers increasingly work.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#154The problem that the article doesn't address is that users don't actually seem to mind using terrible software so long as it solves the problem they face better than not using it. I could list literally hundreds of half-assed, broken, bloated applications that I've encountered in the past 25 years that have done very well simply because they kind of solve a problem a bit for the user. Pushing out something completely…
> A high level of quality in software is not important unless you're entering an already well-served market. I wish it was.
Somewhat weird mindset. It is natural that when a new market gap is discovered, the first iteration of products are crappy and do the job just barely. Applies to software, cell phones, forestry machines, water toilets. Having a mindset where everything should be perfect from the start will get you nowhere.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#155Earlier quoted context omitted.
Yeah, this is an unfortunate truth that Agile has to confront; there may be hard coordination deadlines. Or, in startups, a financial "runway". On the other hand, setting a deadline can't force something to be possible, it can only force people to work harder and more painfully towards it. I'm sure the Amazon drone delivery failure had a date target, for example. And there have been plenty of failed "big bang" IT mig…
Agile is fine with fixed due dates. Fixed features on the other hand...
Exactly this. You create a minimum set of features that must be shipped by the due date. You negotiate on this, adjusting the minimum set or the due date correspondingly.
The desired features beyond the minimum set are accepted as being at risk of remaining unimplemented if the due date can't be shifted further to the right. They become stretch goals that may be achieved by the deadline, or will be worked into a second effort during the maintenance of the system.
Agile (especially some of the stuff in the Lean Software world) is very well-suited to this kind of development. As are the classical evolutionary or iterative & incremental models.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#156The problem that the article doesn't address is that users don't actually seem to mind using terrible software so long as it solves the problem they face better than not using it. I could list literally hundreds of half-assed, broken, bloated applications that I've encountered in the past 25 years that have done very well simply because they kind of solve a problem a bit for the user. Pushing out something completely…
A classic screed on the same topic: https://web.stanford.edu/class/cs240/old/sp2014/readings/wor...
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#157I know it's just an illustration, but that "Code done with care" section is making me twitch.
No transaction context to rollback if one of the steps fails.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#158Earlier quoted context omitted.
You worked on that app yourself alone, right? If so, I believe your app belongs to a different plane of existence. Programming (one programmer working alone without too much money/time pressure imposed by others) is quiet different from software engineering (multiple programmers, stakeholders, designers, etc., with time and money constraints). Everyone loves programming (and so doing programming usually leads to high…
I would say a lot of this confusion comes from the word engineer. Building software is not like building a bridge. You can't design it first and then go and build it. So I would say engineer is a poor term, but also the only one we've got for now.
Hmm, 'developer' has a cheerful kind of vagueness about it - it comes close to describing the iterative process of starting to write something one way, then realizing your original approach wasn't quite right and rewriting it. At least, I don't think mechanical engineers do that too often...
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#159Earlier quoted context omitted.
To list just a few such slipping projects outside the software realm: * Space Launch System * Boston's Big Dig * New Berlin-Brandenburg Airport
The Olkiluoto 3 nuclear power plant in Finland. It’s a new type of reactor and one of the only nuclear projects in the West. Construction started in 2005 and the plant was supposed to be online in 2010. Eleven years later it’s still not operational. Original budget was 3 billion euros. Current estimate is over 11 billion.
Wise moves on the part of the project proponent, had they presented their project with a 17 year construction and 11 billion euro budget it never would have been started.
Humans are optimistic. If we knew in the beginning how long something will actually take we never would start many things.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#160Earlier quoted context omitted.
I don't like this definition of Software Engineering that necessitates a team of Other People. Perhaps I'm outright wrong that such a definition just shouldn't be. Even in that case, I just don't like it. :)
If you broaden the definition of Other People to "you, 6 months from now" and "you, 6 months ago", then many SE principles still apply. Where SE principles don't apply is toy, one off scripts that you just hack together to get a single thing done and require no maintenance like a lot of stuff in science.
Absolutely true. Not even 6 months needed.
When I do stuff for myself I apply the same principles I apply at work. It's insane how easy it is to change stuff later on. Didn't think about this use case before but now you do? Because I have properly maintainable code that is readable its very easy to change and changes are only needed in one place instead of all over the place. Knowledge of the right thing is kept in the right place instead of implicit knowledge all over the code etc.
It also helps to have 'one team be responsible for each service' instead of 'everyone can work on everything'. It's insane how fast you can move if you know the code well and it's maintainable.