TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Driving engineers to an arbitrary date is a value destroying mistake (2020)

290 pointsby vimes656almost 4 years ago

36 comments

onion2kalmost 4 years ago
The problem that the article doesn&#x27;t address is that users don&#x27;t actually seem to mind using <i>terrible</i> 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&#x27;ve encountered in the past 25 years that have done very well simply because they <i>kind of</i> solve a problem <i>a bit</i> for the user.<p>Pushing out something <i>completely</i> broken that doesn&#x27;t do what it&#x27;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&#x27;t work given a particular set of circumstances will still lead to <i>many</i> people using it if the users don&#x27;t have any alternatives and it&#x27;s better than using a piece of paper.<p>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&#x27;t care so long as the app works well enough to do what they need it to do (but they&#x27;re not dumb, they&#x27;ll still pick the least buggy option if there are alternatives..).<p>A high level of quality in software is not important unless you&#x27;re entering an already well-served market. I wish it was.
评论 #28086460 未加载
评论 #28084943 未加载
评论 #28087097 未加载
评论 #28085572 未加载
评论 #28085283 未加载
评论 #28084834 未加载
评论 #28084697 未加载
评论 #28085785 未加载
评论 #28086078 未加载
评论 #28084752 未加载
评论 #28087191 未加载
评论 #28085552 未加载
评论 #28087757 未加载
评论 #28086427 未加载
评论 #28091029 未加载
评论 #28086416 未加载
评论 #28086717 未加载
评论 #28088787 未加载
评论 #28087551 未加载
评论 #28088990 未加载
stupidcaralmost 4 years ago
It seems strange to me that software engineers are so frequently singled out for schedule slippage, when the impression I get is that <i>every</i> novel engineering project suffers from the exact same problem. Projects to design and build new military and civilian hardware and infrastructure always involve budget and schedule overruns of months or years. Can anyone provide convincing empirical evidence that software projects are delayed more than hardware projects of equivalent budget and distinctiveness from previous solutions?<p>A negative comparison often seems to be made between software engineering and construction, but it seems to me that the latter is a unique subfield of engineering, where you have an unusually large number of projects with a roughly homogenous set of constraints and variables. This has allowed those constraints and variables to be studied, understood and mastered to produce a discipline that more closely resembles mass-production. And in those subfields of software that also involve more homogenous constraints, such as the production of standard commercial websites, you do see a more controlled and templated approach, using tools like Wordpress.
评论 #28085781 未加载
评论 #28087426 未加载
评论 #28088060 未加载
mprovostalmost 4 years ago
When I was in the VFX world we had fixed, hard deadlines. Once the release date is printed on a movie poster it&#x27;s not changing. Some parts of the process were easy to estimate since they&#x27;d been done many times before, but on every film there were some experimental new things. Often they would just end up with 2 or 3 different teams working on the same problem. One with a known technique, and one or two trying something new. Then if the new stuff didn&#x27;t work or was taking too long, you could always fall back to the old way. Which wouldn&#x27;t look as good or achieve the effect you wanted, but :shrug:. There was always the chance that you&#x27;d work sometimes for years though and your work would get dropped which was never that fun for the artists involved. Most development teams don&#x27;t have the resources to have an A and B team working on the same problem but it&#x27;s a way to contain risk.<p>The studios use release dates as deadlines basically to contain costs. Otherwise some directors will just keep working on a movie forever (or keep going back to it like George Lucas). Some movies, especially with VFX, are never really done, they just get to the deadline and finish with what they have at that point.
评论 #28087678 未加载
danparsonsonalmost 4 years ago
Alternate view point - driving projects to a specific deadline allows the other departments in the company to coordinate marketing, packaging, and selling the product. These people don&#x27;t sit on their hands patiently waiting for engineers to finish building, their work can take many months just as the development does, and sometimes also involves making tradeoffs to deliver on time. No company wants to wait another year after development is finished before they start earning money for it.
评论 #28085241 未加载
评论 #28092962 未加载
评论 #28085847 未加载
dangerfacealmost 4 years ago
There is nothing wrong with working to dead lines estimating and planing development and releasing software thats good enough not perfect.<p>The problem is when people start trying to change the plan half way through execution, non tech people will constantly try to do this because they are clueless its the project leads job to tell them no.<p>When your manager asks you &quot;if anything can be done to pull those dates in.&quot; you say &quot;no&quot; problem solved, until your line manager goes to the big boss who asks the same thing and do you know what your answer is? Thats right its &quot;no&quot;. When the big boss says you have to do something then tell him &quot;I cant magic more time you need to cut features&quot;, big boss and manager will argue their point but unless you can do magic your point remains the same.<p>I know its scary being blunt with your big boss but as a senior developer thats your job.
评论 #28087983 未加载
评论 #28087508 未加载
评论 #28087483 未加载
评论 #28092855 未加载
评论 #28087820 未加载
评论 #28087289 未加载
stephc_int13almost 4 years ago
There is a counter intuitive thing about software project estimation that took a long time for me to discover.<p>The more rigorously you try to analyse the problem, cutting it into smaller and smaller parts, the more error you introduce, reducing the value of the estimate at each step.<p>Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences.<p>If you don&#x27;t have previous experience with similar projects, then you should not even try to estimate.
评论 #28086002 未加载
评论 #28085312 未加载
评论 #28085173 未加载
评论 #28089398 未加载
altitudinousalmost 4 years ago
Once you&#x27;ve been around in this software business for long enough you see the same articles written over and over again... there will always be articles about estimating software, yet there is no solution to this problem.<p>Anyhow, it doesn&#x27;t matter. Software devs are the lowest cog, they don&#x27;t get to extend the delivery date. All the layers above - management, marketing, sales etc need a date to work to to deliver their work, and they generate the $$$. No-one cares if the software is low quality, as long as it is delivered. Dev team can do further updates to bug fix after delivery. The end.
评论 #28085500 未加载
评论 #28086304 未加载
评论 #28087059 未加载
评论 #28088096 未加载
darkersidealmost 4 years ago
I&#x27;m not convinced an arbitrary date is a bad idea, and in fact, I continue to think it&#x27;s a good one. If you don&#x27;t have a point in time you are optimizing for as a developer, then why wouldn&#x27;t you continue to gold plate and improve your code? Once you have a ship date, you know when it is time to knock it off and start heading downhill.<p>The real problem here is the leadership deficit. The manager got pushback on the estimates, and instead of explaining the reasoning and <i>bargaining on scope</i>, he caved and kicked the can down the road by letting the estimates crumble. Yes, estimating is hard, and you are probably going to be wrong, but once you have your finger on the scale to get a desired result, you can&#x27;t blame that on the difficulty of estimating. Just deplorable leadership.
评论 #28096215 未加载
评论 #28087311 未加载
评论 #28086060 未加载
senkoalmost 4 years ago
The article is full with interesting nuggets of wisdom, but I found it all over the place, as it mixes several issues (all of them important) into one.<p>The article mentiones &quot;high-value&quot; projects (vs &quot;low-value&quot; projects), but the actual distinction made is between high-effort (new framework, new kind of product) and low-effort. Value and effort are not neccessarily correlated, indeed by the end of the article the team has had a high-effort project that resulted in a low-value product.<p>It also conflates product discovery (what will actually have value to the users) and technical discovery (how do we build the damn thing). It starts with the technical challenges (and I totally subscribe to the notion that estimating anything that you&#x27;re not doing routinely is Dangerous, see <a href="https:&#x2F;&#x2F;blog.senko.net&#x2F;bridges-vs-apps" rel="nofollow">https:&#x2F;&#x2F;blog.senko.net&#x2F;bridges-vs-apps</a>) but then veers off into describing mismatch between features built and value add (also a very important subject, but a different one).<p>I would love to see author expand each of the sections into an own article and explore these things in more depth!<p>The most underwhelming part for me are the recommendations at the conclusion. So (focusing here on tech aspects) if &quot;Something by Date (tm)&quot; methodology is bad (which I can agree with in principle), the solution to &quot;let competent engineers prototype [the app] in 3 or 4 different frameworks&quot;, ie . &quot;give your engineers unbounded time&quot;? All developers (and I am one) wish they&#x27;d have more time to implement things properly, so that&#x27;s not a new insight. But it&#x27;s not actionable either - &quot;give more time&quot; then turns into &quot;Something by Later Date (tm)&quot;, which is basically the same problem, just with more money (and thus stakes) involved.<p>I hoped to see an exploration into how to creatively solve for &quot;can we deliver value&quot; + &quot;we have this budget and time&quot; constraints.
nabla9almost 4 years ago
Chapter 11. Plan to Throw One Away<p>Chemical engineers learned long ago that a process that works in the laboratory cannot be implemented in a factory in only one step. An intermediate step called the pilot plant is necessary to give experience in scaling quantities up and in operating in nonprotective environments. For example, a laboratory process for desalting water will be tested in a pilot plant of 10,000 gallon&#x2F;day capacity before being used for a 2,000,000 gallon&#x2F;day community water system.<p>Programming system builders have also been exposed to this lesson, but it seems to have not yet been learned. Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built.<p>In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.[2] Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.<p>The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering that throwaway to customers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down.<p>Hence plan to throw one away; you will, anyhow.<p>-- Frederick Brooks, The Mythical Man-Month
评论 #28087878 未加载
gregjoralmost 4 years ago
Which is more likely: Businesses invent truly arbitrary deadlines for the hell of it, or the “engineers” don’t want to pay attention to business requirements and competitive pressures?<p>When so-called engineers stop spending half the development schedule choosing a framework and the other half trying to make their dev setup work on everyone’s personalized laptop they will have some credibility complaining about “arbitrary” business goals and requirements.
评论 #28238561 未加载
评论 #28085042 未加载
评论 #28086454 未加载
评论 #28089525 未加载
Closialmost 4 years ago
Well the counter argument is that shipping later also destroys value (because value can only actually start to be accumulated once a product has shipped).<p>But this article doesn&#x27;t seem to address the obvious counter-point.<p>For instance, take the below:<p>&gt; wouldn&#x27;t you rather run a your customer&#x27;s payments through code that is at least attempting to handle error conditions, rather than some happy path code that just assumes everything works?<p>But this doesn&#x27;t address the obvious issue which is, there is value destroyed (or not created) by not allowing customers to pay you earlier.
评论 #28085388 未加载
评论 #28084806 未加载
commandlinefanalmost 4 years ago
&quot;Our boss can&#x27;t judge the quality of our work, but he knows when it&#x27;s late&quot; -- Dilbert
评论 #28090161 未加载
bjarnehalmost 4 years ago
The whole point of organizing things in the first place, is to reduce or remove uncertainty and risk, which cannot be done with software projects.<p>Software engineering is similar to writing a book, or a movie script; but it is mistaken for some advanced reorganization of numbers in an Excel sheet.<p>Normal leadership training relies heavily on deadlines to &quot;move things forward&quot;, or force us to &quot;see where we are&quot; etc. This only creates stress on the creators themselves, making them far worse at actually creating something. This is something all developers know, and this is why companies started by developers often have a very relaxed attitude towards work. I.e. the dart board, pool table, or beer taps are not there to make the office &quot;look cool&quot;, it&#x27;s there to make a relaxed atmosphere, where you work when you are &quot;in the zone&quot;, and relax when you are not.<p>Everyone who writes movie scripts, books or software knows that you can do more in 4 hours of when you are in &quot;the zone&quot;, than in 80 hours in an open landscape, where days are split into short work hours, disturbed by status meetings about progress etc.
webarchiveralmost 4 years ago
Work expands to fill the time you have. If you don&#x27;t set a goal, you&#x27;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.
评论 #28084708 未加载
评论 #28084761 未加载
indymikealmost 4 years ago
There are three kinds of deadlines: fake deadlines, contract&#x2F;revenue driven deadlines and reality driven deadlines. Most problems with deadlines I&#x27;ve seen come from chronically mislabeling the deadline (e.g. sales don&#x27;t close, so engineers start ignoring revenue driven deadlines). Fake deadlines sometimes are necessary to get things to some finished state, but they should be used very sparingly. Deadlines should be honest, and when something changes (e.g. some other team is going to be 3 weeks late on their part of the product so being on time doesn&#x27;t matter) the deadlines should be quickly adjusted. Deadlines are a work-planning and asset allocation constraint, and will cause very bad decisions if they are not understood and managed well.
RandomLensmanalmost 4 years ago
A better solution ten years later might not be a solution at all when running a business. So it cannot be just open ended.<p>The point I take away from this more: poor planning and execution processes destroy value. It is not an &quot;us&quot; vs &quot;them&quot;. Have clear responsibilities for removing internal&#x2F;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&#x2F;outcome.
bryanrasmussenalmost 4 years ago
this seems to mainly be relating to pushing to an arbitrary date for creating something new but still sometimes dates are given to us because of some sort of regulatory reason or a company contract meaning that something needs to be done by a certain time - before anyone says don&#x27;t make contracts like that: The Danish and Swedish parts of Thomson Reuters WestLaw were sold off to an English holding company, as part of the sale the sold off parts were allowed to remain on WestLaw for one year after which they would have had to pay approx. $165,000 dollars a month.<p>Obviously we got off of by that arbitrary date, and if we hadn&#x27;t that would have been a value destroying mistake.<p>on edit: the weird monetary amount is my attempt to turn to U.S.D the DKK amount at the time which was 1 million dkk - iirc the dollar was at a low but it was between 161 - 165.
评论 #28085410 未加载
vagrantJinalmost 4 years ago
To be fair, Engineers engineer and wouldn&#x27;t mind spending twenty years engineering and discovering new paradigms and interesting things to get 1.2% gains. Deadlines force the issue to put the wandering mind of the engineer in a straight-ish path. Not perfect, but the alternative would take a lifetime.
bob1029almost 4 years ago
There is never going to be one clear way to deal with scheduling around software projects. The number of variables involved is vast.<p>I view schedules around software projects as a few different things:<p>- Public expectations for specific deliverables that your customers can align to, many times with a calendar unique to each customer.<p>- Internal carrot&#x2F;stick for managing constraints around active feature development. If you have an infinity budget (film&#x2F;AAA gaming), you might be able to run less-bounded parallel efforts as noted elsewhere in this thread.<p>- Orthogonal operational concerns (planned outages, et. al.)<p>- Roadmap for strategic product development that the investors can think about<p>So, when someone says something to me like &quot;are we still on track for end of the week?&quot;, I have to provide an extremely qualified series of responses and ask more questions.
timmgalmost 4 years ago
I always tell my PM:<p>You can pick a feature set or a launch date. You can&#x27;t pick both.
评论 #28096412 未加载
wildealmost 4 years ago
I’ve lived through a project managed like this. The problem isn’t the date. It’s the unwillingness to prioritize and cut scope when the bottoms up estimates show your first version is too big.
mwcampbellalmost 4 years ago
&gt; The Big Boss is a pressure kind of guy, he believes that people work best when they are under pressure and if pressure isn&#x27;t applied, they waste a lot of time on unnecessary things. [...] he goes away thinking what he already knew, that engineering is just screwing around instead of getting the project done.<p>Sadly, he&#x27;s often not wrong. My own work ethic isn&#x27;t exemplary, and sometimes in the absence of pressure I slack off. I&#x27;m surely not the only one. I don&#x27;t know what to do about it though.
评论 #28087592 未加载
papitoalmost 4 years ago
This is a combination of management not asking for input, pulling a deadline out of their asses, and engineers chronically low-balling their own estimates (while the managers think it&#x27;s the opposite).<p>My pet peeve is when a deadline is a &quot;round&quot; date. 1st of the month, 1st of the year. WHY? Your users don&#x27;t give a shit. If you are not publicly committed to a launch date, which you should never be, until your product is <i>ready</i>.<p>That said, internal deadlines are a moronic thing to have. These should be <i>goals</i>.
brightballalmost 4 years ago
Yep. I’ve preached this whenever I talk about dev process. The best way I’ve heard it framed was using two different terms: deadline and target date.<p>Target dates are internal goals, not tied to anything other than a rough estimate or a day somebody made up.<p>Deadlines are tied to contractual obligations, events, etc.<p>If it’s not a real deadline it’s a target and targets can move. Real deadlines mean you start talking about how to trim your requirements to have a shot at hitting it.
评论 #28089881 未加载
jdauriemmaalmost 4 years ago
The most effective manager-engineer relationships I&#x27;ve seen are built upon a problem-solving culture, rather than feature-shipping. If your goal is to solve problem X in Q3, your managers and engineers have far more flexibility to collaborate and compromise. If your goal is to ship X features in Q3, your managers have less flexibility and your engineers have an incentive to cut corners.
toolslivealmost 4 years ago
time, scope, quality, cost. pick 3, the 4th will be a function of the 3 parameters you picked. So you need to understand what&#x27;s important.<p>If you&#x27;re building a Mars lander, time is everything because if you miss your launch window, you need to wait 18 months for the next one. Most of us are doing something else.
yeneekalmost 4 years ago
Author is wrong about the underlying cause of that disaster.<p>From my point of view, the cause is different:<p>1. Lack of design a.k.a. designed by coders &gt; At 5 months the team has happy path coded the entire feature list, the screens are ugly and non-intuitive, ...<p>It&#x27;s obvious, that the product wasn&#x27;t designed. Feature list isn&#x27;t design. Competitors app isn&#x27;t design. When you have UX&#x2F;UI&#x2F;API designed, it doesn&#x27;t happen that the result product is ugly because of the lack of time. Lack of time may cause, that there will be nicely looking, but slow&#x2F;incomplete&#x2F;unreliable product. You need blueprints before building. It can be designed upfront by one designer who is in contact with user and stakeholders. When not, it has to be designed during coding by software engineers which are drowning in technical details and cut off from users. So just having some more time wouldn&#x27;t make it a good product.<p>Also with some plan, they could have created estimation based on something. That would help them to get a realistic timeline.<p>In the end, the boss and PM should have known better.
MattGaiseralmost 4 years ago
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&#x27;s problem.
评论 #28088556 未加载
bitwizealmost 4 years ago
Deadlines are a fact of life. Without them, nothing would get done in a timely fashion. If you do not know how to work to a deadline, you are not a professional.
BLanenalmost 4 years ago
The diagrams in this article are a value destroying mistake
fnord77almost 4 years ago
I know it&#x27;s just an illustration, but that &quot;Code done with care&quot; section is making me twitch.<p>No transaction context to rollback if one of the steps fails.
ruskalmost 4 years ago
It’s like skeumorphism. It’s not ideal, but it’s a common or goal reference point that doesn’t need exhaustive explanation.
23B1almost 4 years ago
Can someone tell the engineers I&#x27;ll be happy to give them unlimited time if they will give me unlimited value?
评论 #28085551 未加载
JoeAltmaieralmost 4 years ago
Just-in-time software has been a thing for a long time. It&#x27;s not a mistake.
bykhunalmost 4 years ago
Love the format of the talk converted to the text