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.
The idea is that it does what it says on the tin, without fanfare, robustly, usably, accessibly, localizably, and dependably; providing a user experience that gets out of the way of the user, in a manner that does not surprise the user (even "good" surprises can be an issue. Boring software can be just what the doctor ordered).
In my book, that's the definition of "quality."
I'm working on an application that has been over a year in the making. Its functionality is something that I could have popped out in a month, but making sure of the Quality of the app has necessitated that I spend a great deal more time, "polishing the fenders."
If this were a commercial app (it isn't), then it would have been unbearably expensive for a startup.
I tend to write test harnesses in a day or two, that have similar levels of functionality to this application.
High Quality is significantly more expensive than even "decent, but lesser" quality.
What happens if you release it and it turns out that nobody likes it? I'd have preferred to spend a month releasing a lower-quality app, and then spent 11 months improving it (while people use it and I learn more about what they want) rather than take a year releasing a high-quality app nobody wants to use.
This assumes you aren't just building it for fun, though, in which case building it is the point, and you don't even need to release it afterwards.
There's so much trash everywhere that is earning millions (book reading apps, silly chart-db software, proprietary SQL databases etc.).
I was quite shocked by the levels of disfunctionality in the software engineering sections of the company I worked at yet still, the company has huge success. We basically got requests from the product team to make something work in a day or two and even though it was completely horrible code that absolutely paralyzes us at some moment in the future, the company still reigns.
I've been saying that for a long time, but I don't see as a problem in itself, but as a fact of life.
The problem comes because people get the wrong impression that "state of the art" is always a compliment and terrible usability is best of possible worlds.
I'm reminded of this every time I try to teach my mother anything about Android or Windows. Or even when I must deal myself with a new app with its quirky "state of the art" GUI.
Windows and Android keep reinventing the same wheel even though (especially Windows) is basically still in "Windows 95" mode - getting fancy with a phone ui is just trash.
Solving the right problem the wrong way is more important than solving the wrong problem the right way.
As an engineer, that has been one of the most important lessons for me in my career so far.
But also, solving it the wrong way may create an opportunity to do better.
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.
This is a great phrase that I'll have to remember. Pretty much all enterprise sales is "whaling".
I’d say better way to say the same thing would be ”Unless you are building something truly innovative and unique that people must use anyway no matter how bad the experience is, software quality matters.”
The cultures that tend to ship buggy software also tend to be the sort of cultures where the quality doesn't improve in response to a competitor however. But so far almost every software business has ultimately failed so being on top for a decade because you shipped some of the solution earlier works better. Customers are more than happy to buy exceptionally buggy software and games.
This is true and, once you get over the myopic code focus that most of us shared in university, incredibly self-evident. "Users prefer to use the thing that solves their problem better than not using the thing." I mean... yes?
The real takeaway is that "software quality" means something very different to users than it does to developers. Developers want efficient, ergonomic libraries, aesthetically pleasing logical structures, and elegant software designs. That's what we call "quality". Users just want their damn problem solved, and if they can GET software like that which solves that problem, then you bet they'll buy it, but if they can't then anything which actually solves their problem is far better than doing it by hand.
This was the first big lesson I learned out of uni and it's stuck with me ever since. If you're interested in making commercial software, you're not there to solve the problems YOU think are important, you're there to solve the problems YOUR CUSTOMERS think are important.
And don't get me started on security/privacy issues.
In other words: users do care. They just don't have a choice.
That's not the same than users "not minding" bad software.
Another. Industries that are oriented towards tradeshow or holiday launches. It ain't like they're going to move NAB or Christmas just for you. Inevitable feature pruning occurs.
Having said that, I wonder how many of the great fortunes have been built on horrid, half-finished websites and associated software that were all about being first out of the gate and heavy marketing.
An interesting subcase is software that is difficult or impossible to update vs. immovable deadlines. I guess in a world that consists entirely of one silly internet surveillance marketing company after another is doesn't really matter much anymore.
This is ZERO snark, but I'm genuinely curious for lots of examples. I ask because I'm confronted with this problem ALL THE TIME working at startups that obsessively focus on visual elements that won't move the needle, versus being obsessive about solving pain better than others.
I need to start building a list that I can just pull out at a moments notice.
Would love to hear more!
Even then, it's not what's important. The core important thing in the product is that it does a job the customer needs done. If you write a program that provides complete feature parity with the incumbent with better engineering principles, you're going to lose because the engineering principles aren't the job the customer needs done.
Where it will make the difference is that your company will be able to respond to changing requirements better than the incumbent.
So solid software engineering is never the product for the customer. It might be the product for the company, depending if the company actually needs the improved developer efficiency and happiness it provides.
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.
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.
* Space Launch System
* Boston's Big Dig
* New Berlin-Brandenburg Airport
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.
In the latter case, like so many government sponsored engineering projects, the company has no real long term incentive beyond what is written into the contract. Management isn't driven by the software being produced so much as meeting the contractual requirements that result in payments. In my experience, software contracting houses are a lot more likely to hold schedules over the heads of developers, and that's purely driven by the terms of the contract (billable hours). In contrast, even when I have been a contractor for a company that is building the product for itself, they tend to push for the goals of the project while ensuring it meets the needs of the company. The difference in pressure as a developer is quite substantial.
It follows this trend I've seen across the board in business throughout my career, of mistaking the last hair on the last yak for the entire job. The classic example is documentation. "Hey the electrical drawings are due on Thursday the Aprilteenth, can you have them ready by then?" Oh sure, that's two months away, that's plenty of time to bang out some drawings, right? But wait! The drawings depend on the functional specification. And the functional specification depends on the functional description. And the functional description is blocked on some TQs from the client. And you're still expected to produce these drawings by Thursday Aprilteenth when realistically you're not going to see even a first draft of the functional specification until the Wtf'th of August. But now it's your fault that the drawings are late because you weren't paying attention and you agreed to a due date that didn't depend on your dependencies.
I take this one particularly personally because I'm in industrial automation and, almost by definition, we get the last bite of the pie on every single project. Sure, there are some things we can start early but on the project-specific parts, generally we're waiting for everyone else to do their job before we get priority.
"Can you help us with the motion control software for AwesomeBot?"
Sure, no worries!
"Just remember we need AwesomeBot running by Thursday."
Hey cool, you present me with an AwesomeBot-shaped shell and I'll fill it with closed-loop-ey goodness.
"It's Friday, why isn't AwesomeBot doing somersaults like you told us it would?"
Uh well, AwesomeBot is lying disassembled on the mechanical workbench and half the laser cut sheet metal hasn't arrived.
"But you told us Thursday! Okay, we'll finish putting AwesomeBot together and let you know when it's done."
<fast forward 17 months>
"Hi remember us? We're AwesomeBot inc."
Oh hey how's it going with that?
"We've got AwesomeBot fully assembled and we're ready to go! Can you come down tomorrow and install the software on it so it does everything we ever dreamed of including anything we might have imagined it might do in the 17 months since we last saw you?"
Uhhhh... so how's testing going, have you switched it on yet?
"No, why would we do that? We were only waiting for you!"
We are very deliberate about setting deliverable dates in time after the required inputs by others are available, and when inevitably they are not, we have a spreadsheet sent to the customer every 2 weeks which shows what information we are missing and the delay that is causing to our progress. As we are liable for damages if we delay the project it is necessary for us to have the proof that we did not cause the project to be behind schedule. This often means having these difficult conversations only a month in to a year long project when vendor drawings we were promised are not delivered.
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.
–Rosalie Maggio
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 migrations delivered by similar immovable deadlines.
It's so you can (hopefully) have an educated understanding of setting that deadline, and then how you're progressing towards it. It's so if you're not on track to deliver, you can make more educated decisions about cutting scope, or adding resources (yes yes yes, i know).
But fundamentally software development has 1000 to 1000000 more moving pieces than a cake, generally a research project, like building a new type of aircraft engine. Except, imagine it was a really new type of engine that was being built based on an alien landing. But they could not get into the engine to see how it worked because it was an unknown alloy. So they were trying to invent a new type of anti-gravity drive based on a few clues.
I mean we are not trying to defy gravity, but there a shitton of unknown unsolved problems. You can't promise or create marketing for a feature unless we already know it's possible. For starters.
But the issue is worse than that. What generally happens is once one part of the new engine is barely working, they demand another new invention that has to be completes in the same deadline before the other one has corner cases examined even.
I'm a software developer, have been for my whole career, so I know what building software is like. And while I agree that sometimes there are significant unknowns to resolve, and these can require large amounts of time, still the company has to market and prepare to sell the product before it's finished, otherwise as I said the company has to wait months or even years to get paying customers, by which time a) they'll have burned a huge amount of money without seeing any return and b) they may have missed their market opportunity. In the case of B2B transactions, the customer may have made significant operational decisions based on the deadline they've agreed to, and the supplier missing that deadline can have serious repercussions for a relationship that may have taken many years to build.
And come on, let's be honest - most of the time we're not designing a new type of aircraft engine. We're building something that looks very much like existing engines in general form, but with specifics that are different. I know it's hard, and I know estimates are a significant source of pain, but we need to have some sympathy for the rest of the company that's ultimately bringing in the piles of money that we get paid.
If the choice is between releasing kinda-working, but unpolished software, or throwing a developer's monthly labor cost out of the window every single day, these management anti-patterns suddenly make much more sense
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.
The challenge is that there are no hard rules and it's highly dependent on the context. That requires mutual understanding and trust between the business and development.
This. They could hire any random chump to say they're right. If you're the expert, they hired you to tell them whether they're right.
Of course, not all managers understand this but the sooner you realise you're working for one who doesn't, the better.
Just "finishing up" a project of "6 months" where we went from reasonable to unreasonable scope, and I was the only one that said it was unlikely we were going to finish on time, weird that I was the only non-contractor....
Almost a year a shoddy version that's just copying data from their existing product is only mostly a buggy mess!
That's a problem because many people do not have the luxury of quitting for another job easily.
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.
The problem is estimation errors are not symmetrically distributed because engineers chronically underestimate how long something will take, and the problem is exacerbated by management pressure giving them an incentive to estimate even lower.
Ever had a task with 4 seemingly “easy” parts where 3 are easy and it turns out 4 requires a big rewrite because of some hacked put in 8 years ago that are now deeply ingrained assumptions in the code?
Often you are asked to estimate a 10k part project!
The distribution of delays is pathological, too. It's not normal or poisson or anything nicely amenable to analysis.
We're trained to cut big problems in small parts to solve them.
This is more closely related to human psychology than pure logic.
Jokes aside I think accumulation of errors together the fact that time estimations are hard and Parkinson's law is the fatal flaws with Agile.
> Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences.
This is my experience too. It is somehow easier to estimate big scopes then many small that sums up to the same scope. Also you get a better feeling of how far you have come when looking at the big scope then when digging down to the details.
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.
It takes a lot of trust and maturity and skill (from both technical and business side) to have continual value delivery instead of estimates. This is possible but not the common case.
Heck I personally just did this. I scoped out a story. Then realized I had underestimated it because there was at least 2 tech stacks in the thing I had not used much. So I had to basically drop what I was going to do and figure out some PoC on that. THEN I could write my code.
My favourite is watching successive generations discover thin client vs. fat client over and over again.
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.
At my current employer, managers love to use this term. We are asked not to gold plate.
And yet they’re the least qualified to decide what is gold plating.
Case in point, gold plating in my managers’ minds means: “code reviewing, refactoring, automating code quality (linting in pipeline etc), or writing any kind of test”. To the rest of us, this is far from gold plating, nice to have, or optional. Yet this is what gets cut every single time. And then we’re asked why we suck so much and “just fixing that one little button” takes a month and breaks five other things.
Refactoring is a bit different in my mind. I often discover better ways to write a piece of functionality while I am writing it. Sometimes it's worth essentially starting over, and sometimes it's not. That decision IMO should be heavily influenced by business deadlines. There are times to push back the deadline because of a major refactor, but they damn well better be a rare exception, and you (and your manager) damn well better be able to explain the business reasoning behind it.
Lumping poorly judged refractors, last minute pet features, and optimizations (actual gold plating) in with critical technical practices like testing and review is probably part of the problem in your organization..
Because it feels good to complete work and I would like to move on to other features. How long can you work on improving a single piece of code before getting bored?
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.
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
i must say, the mythical man-month should be a must-read* for any technical managers or execs in a tech org (hmmm throw devs in that list too)
*and maybe re-read every year to keep it fresh in mind
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.
It's called "development" not "Bam, it's done!" The best companies allow proper time for the development process to take place and have a proper team structure. Companies where everything is discussed as a team and you succeed and fail as a team. Proper agile teams which communicate at every step, with developers, testers, a scrum master, a business owner and a manager.
If you don't have that, you're basically not a proper development team, you're more of a startup that can't afford a proper development team. Nothing wrong with startups, but if you are a startup then you have to deal with your own weaknesses and shortcomings and take your failures on the chin.
From experience, in their career, engineers not only need to excel technically, but are also forced to pick up everything from UX, methodological BS (from Scrum to Itil) to domain specific know-how in multiple fields or areas. Since many managers do not know what they're doing, senior engineers often times end up being de facto management consultants as well. If you are working in a business environment (as opposed to writing low-level drivers or whatever) it's almost impossible to not pick up on what's going on around you.
How many banking managers know how to code? How many engineers working in banking know at least something about the processes, compliance issues, how the org is structured, what the competitors are?
The stereotype of the autistic programmer who is only interested in shiny gadgets and tech needs to die.
As a freelancer I have to get to know the business my customers are in, I can’t just focus on purely technical things most of the time. Many times I have described my work to other programmers and heard how they want to be left alone to code. I take over legacy software and failed projects for a living. The two main reasons in my experience for software dev project failure are (a) developers did not bother to gather and understand requirements but rushed to start coding, and (b) poor communication with the customer and stakeholders. Those faults may come from arrogance or inexperience, or both.
Management failed to communicate the limitations of the investment by investors to finish a project. In this case 4 months window of having an additional small team to build it. I had to pay very close attention to extract that information, my inquiries into it were rebuffed. My contract held the most clues.
Engineers didn't bother to listen to the clues and started a design by committee loop that was going to take a year+ to finish. They were much more interested in new shiney things than the financial business restrictions and this attitude was enabled by management.
We managed to finish something within the investment period only because I pushed and prodded at every turn trying to finalize decisions and cut out scope, without managements help, to do so. The manager who tried to shield engineering from deadlines didn't help this despite the train wreck I tried to communicate. At the end of the investment period all the extra engineering hired for the task were let go and the regulars were left to finish the demo we managed while maintaining their normal work load. It is now almost a year later it still isn't released.
While there are places where tone deaf management creates death matches for no good reason. There are apparently also places where management let's engineering walk all over them like a spoiled child with no grounding in financial realities.
The stereotype has been kicked to death, dismembered, burned, rebuilt as an effigy and burned again throughout the years.
The stereotype of the evil and incompetent manager who is only interested in ruining the lives of their underlings, who would solve the world's problems if only left alone to do their jobs, is still going strong.
But if you demonstrate that you understand things from the business perspective, they are much more receptive to making adjustments.
Product managers like to gold plate things as much as engineers. There is usually some fat you can trim from the scope to make a deadline.
The problem begins when deadlines are used to limit agency rather than support it.
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.
The truth is that sometimes speed to market is more important than quality, and visa-versa. Handling sensitive credit card data? Sure quality and security are important of course. Implementing a payment gateway to bootstrap a company where that is 1 of 100 tasks before go-live? Hack away and go as fast as possible, and worry about improving it later!
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.
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.
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.
If you fix the dates, something else has to give. If time, cost, and scope are all fixed you're going to fail, almost guaranteed. There are always unknowns and in this scenario the only thing you've allowed to flex is quality.
I'm not saying you can't come in on time and under budget. This article spells out the dysfunctional dynamic of date pressure. By creating this much pressure from the beginning, you create an environment when corners are cut from the beginning and the problem compounds over time. The pressure-cooker mindset of management kills the quality of the project, even if the estimates did turn out to be reasonable.
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.
You can pick a feature set or a launch date. You can't pick both.
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.
Just speaking for myself, but I think better when I'm not pinched between two projects both demanding preference and priority over the other. I can maintain a clearer mind when I don't have people breathing down my neck about deadlines they set and then broke.
Sure, one learns to navigate those situations and maintain an even keel, but still one is obligated to respond in a professional manner to those inquiries and meetings and other emotionally manipulative games people play to get their way when in a crunch. Working through those things still requires time out of day and energy out of mind. Both of those latter resources are limited.
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.
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.
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.
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.
No transaction context to rollback if one of the steps fails.
