by vimes656 on 8/6/21, 7:40 AM with 200 comments
by onion2k on 8/6/21, 8:37 AM
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.
by stupidcar on 8/6/21, 10:33 AM
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.
by mprovost on 8/6/21, 12:56 PM
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.
by danparsonson on 8/6/21, 9:02 AM
by dangerface on 8/6/21, 1:53 PM
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.
When your manager asks you "if anything can be done to pull those dates in." you say "no" 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 "no". When the big boss says you have to do something then tell him "I cant magic more time you need to cut features", big boss and manager will argue their point but unless you can do magic your point remains the same.
I know its scary being blunt with your big boss but as a senior developer thats your job.
by stephc_int13 on 8/6/21, 9:18 AM
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.
Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences.
If you don't have previous experience with similar projects, then you should not even try to estimate.
by altitudinous on 8/6/21, 10:48 AM
Anyhow, it doesn't matter. Software devs are the lowest cog, they don'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.
by darkerside on 8/6/21, 10:04 AM
The real problem here is the leadership deficit. The manager got pushback on the estimates, and instead of explaining the reasoning and bargaining on scope, 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't blame that on the difficulty of estimating. Just deplorable leadership.
by senko on 8/6/21, 9:05 AM
The article mentiones "high-value" projects (vs "low-value" 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.
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're not doing routinely is Dangerous, see https://blog.senko.net/bridges-vs-apps) but then veers off into describing mismatch between features built and value add (also a very important subject, but a different one).
I would love to see author expand each of the sections into an own article and explore these things in more depth!
The most underwhelming part for me are the recommendations at the conclusion. So (focusing here on tech aspects) if "Something by Date (tm)" methodology is bad (which I can agree with in principle), the solution to "let competent engineers prototype [the app] in 3 or 4 different frameworks", ie . "give your engineers unbounded time"? All developers (and I am one) wish they'd have more time to implement things properly, so that's not a new insight. But it's not actionable either - "give more time" then turns into "Something by Later Date (tm)", which is basically the same problem, just with more money (and thus stakes) involved.
I hoped to see an exploration into how to creatively solve for "can we deliver value" + "we have this budget and time" constraints.
by nabla9 on 8/6/21, 9:35 AM
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/day capacity before being used for a 2,000,000 gallon/day community water system.
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.
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.
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.
Hence plan to throw one away; you will, anyhow.
-- Frederick Brooks, The Mythical Man-Month
by gregjor on 8/6/21, 9:13 AM
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.
by Closi on 8/6/21, 8:56 AM
But this article doesn't seem to address the obvious counter-point.
For instance, take the below:
> wouldn't you rather run a your customer's payments through code that is at least attempting to handle error conditions, rather than some happy path code that just assumes everything works?
But this doesn't address the obvious issue which is, there is value destroyed (or not created) by not allowing customers to pay you earlier.
by commandlinefan on 8/6/21, 3:19 PM
by bjarneh on 8/6/21, 10:31 AM
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.
Normal leadership training relies heavily on deadlines to "move things forward", or force us to "see where we are" 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 "look cool", it's there to make a relaxed atmosphere, where you work when you are "in the zone", and relax when you are not.
Everyone who writes movie scripts, books or software knows that you can do more in 4 hours of when you are in "the zone", than in 80 hours in an open landscape, where days are split into short work hours, disturbed by status meetings about progress etc.
by webarchiver on 8/6/21, 8:44 AM
by indymike on 8/6/21, 1:21 PM
by RandomLensman on 8/6/21, 8:55 AM
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.
by bryanrasmussen on 8/6/21, 9:36 AM
Obviously we got off of by that arbitrary date, and if we hadn't that would have been a value destroying mistake.
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.
by vagrantJin on 8/6/21, 1:57 PM
by bob1029 on 8/6/21, 3:24 PM
I view schedules around software projects as a few different things:
- Public expectations for specific deliverables that your customers can align to, many times with a calendar unique to each customer.
- Internal carrot/stick for managing constraints around active feature development. If you have an infinity budget (film/AAA gaming), you might be able to run less-bounded parallel efforts as noted elsewhere in this thread.
- Orthogonal operational concerns (planned outages, et. al.)
- Roadmap for strategic product development that the investors can think about
So, when someone says something to me like "are we still on track for end of the week?", I have to provide an extremely qualified series of responses and ask more questions.
by timmg on 8/6/21, 2:00 PM
You can pick a feature set or a launch date. You can't pick both.
by wilde on 8/6/21, 12:37 PM
by mwcampbell on 8/6/21, 2:04 PM
Sadly, he's often not wrong. My own work ethic isn't exemplary, and sometimes in the absence of pressure I slack off. I'm surely not the only one. I don't know what to do about it though.
by papito on 8/6/21, 12:12 PM
My pet peeve is when a deadline is a "round" date. 1st of the month, 1st of the year. WHY? Your users don't give a shit. If you are not publicly committed to a launch date, which you should never be, until your product is ready.
That said, internal deadlines are a moronic thing to have. These should be goals.
by brightball on 8/6/21, 4:52 PM
Target dates are internal goals, not tied to anything other than a rough estimate or a day somebody made up.
Deadlines are tied to contractual obligations, events, etc.
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.
by jdauriemma on 8/6/21, 3:12 PM
by toolslive on 8/6/21, 2:39 PM
If you'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.
by yeneek on 8/6/21, 11:27 AM
From my point of view, the cause is different:
1. Lack of design a.k.a. designed by coders > At 5 months the team has happy path coded the entire feature list, the screens are ugly and non-intuitive, ...
It's obvious, that the product wasn't designed. Feature list isn't design. Competitors app isn't design. When you have UX/UI/API designed, it doesn'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/incomplete/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't make it a good product.
Also with some plan, they could have created estimation based on something. That would help them to get a realistic timeline.
In the end, the boss and PM should have known better.
by MattGaiser on 8/6/21, 9:06 AM
by bitwize on 8/6/21, 6:18 PM
by BLanen on 8/6/21, 2:32 PM
by fnord77 on 8/6/21, 4:00 PM
No transaction context to rollback if one of the steps fails.
by rusk on 8/6/21, 8:56 AM
by 23B1 on 8/6/21, 10:46 AM
by JoeAltmaier on 8/6/21, 1:16 PM
by bykhun on 8/6/21, 12:35 PM