Driving engineers to an arbitrary date is a value destroying mistake (2020)
1–10 of 208 posts
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#2[deleted]
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#3The 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 broken that doesn't do what it's supposed to is definitely not going to work (duh!). Pushing out an app that solves the problem of managing shopping lists that has a bug where it doesn't work given a particular set of circumstances will still lead to many people using it if the users don't have any alternatives and it's better than using a piece of paper.
Software quality is important to companies because it means that they can spend more time building features instead of fighting fires, and because low quality represents a threat that a competitor could launch a better, less buggy app. Users mostly don't care so long as the app works well enough to do what they need it to do (but they're not dumb, they'll still pick the least buggy option if there are alternatives..).
A high level of quality in software is not important unless you're entering an already well-served market. I wish it was.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#4Work expands to fill the time you have. If you don't set a goal, you'll never ship. Estimation is not an exact science, but, I rather set a goal post that I can move if I need to than not have one at all.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#5The 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…
Just guessing, but I suspect this is because most software is designed to extract some minimum acceptable investment per person from maximum people, and simply focus on scaling.
When software is designed to focus on extracting maximum investment per person, and focus on whaling vs scaling, then you get loot boxes. Suddenly overall software quality matters a whole lot to the user base.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#6Work expands to fill the time you have. If you don't set a goal, you'll never ship. Estimation is not an exact science, but, I rather set a goal post that I can move if I need to than not have one at all.
"Parkinson's law is the adage that "work expands so as to fill the time available for its completion". It is sometimes applied to the growth of bureaucracy in an organization."
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#7The 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…
Depends on where the “terrible” is. People are happy to work around UI/UX issues so long as they can get the job done (chronic ergonomic issues notwithstanding perhaps) but anything “back end” or “low level” can have catastrophic implications for mere usability. It’s funny because we often seem to ascribe higher priorities to the more visible stuff.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#8A better solution ten years later might not be a solution at all when running a business. So it cannot be just open ended.
The point I take away from this more: poor planning and execution processes destroy value. It is not an "us" vs "them". Have clear responsibilities for removing internal/political blockages, for allowing testing, etc. How to manage new delays and unexpected issues? Who can decide on changes? Organizations can manage to hit target with a reasonable product/outcome.
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#9Work expands to fill the time you have. If you don't set a goal, you'll never ship. Estimation is not an exact science, but, I rather set a goal post that I can move if I need to than not have one at all.
The problem is that negotiations phase where the devs get screwed down on the “price”. This is of course a silly thing for management to do given they are paying by the hour anyway!
Re: Driving engineers to an arbitrary date is a value destroying mistake (2020)
#10It’s like skeumorphism. It’s not ideal, but it’s a common or goal reference point that doesn’t need exhaustive explanation.