I'm not convinced an arbitrary date is a bad idea, and in fact, I continue to think it's a good one. If you don't have a point in time you are optimizing for as a developer, then why wouldn'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. The real problem here is the leadership deficit. The manager got pushback on the e…
Right, but these dates should be intrinsically motivational, and not induce negative stress.
The 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…
The first mover advantage is huge. Once users have already chosen to use your software it will take something substantially better over an extended period of time for most to move over to a competitor that has solved it better. The risk of that happening when you are already making money and solving the problem and have most of the market is small. If you keep irritating your customers and they have a better alternative then you will slowly loose share of the market.
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.
It seems strange to me that software engineers are so frequently singled out for schedule slippage, when the impression I get is that every 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 project…
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.
The 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…
The first mover advantage is huge. Once users have already chosen to use your software it will take something substantially better over an extended period of time for most to move over to a competitor that has solved it better. The risk of that happening when you are already making money and solving the problem and have most of the market is small. If you keep irritating your customers and they have a better alternat…
The first mover advantage is an illusion. Google didn’t invent search or online Email. Microsoft didn’t pioneer personal computing, spreadsheets, or word processing. Facebook wasn’t the first social network. Apple made most of it’s money from markets it entered late iPod, iPhone, and then iPad where the Newton failed. Intel wasn’t the first to build a microprocessor. IBM didn’t invent the computer.
The first mover advantage is huge. Once users have already chosen to use your software it will take something substantially better over an extended period of time for most to move over to a competitor that has solved it better. The risk of that happening when you are already making money and solving the problem and have most of the market is small. If you keep irritating your customers and they have a better alternat…
The first mover advantage is an illusion. Google didn’t invent search or online Email. Microsoft didn’t pioneer personal computing, spreadsheets, or word processing. Facebook wasn’t the first social network. Apple made most of it’s money from markets it entered late iPod, iPhone, and then iPad where the Newton failed. Intel wasn’t the first to build a microprocessor. IBM didn’t invent the computer.
The first mover advantage is an illusion.
I wouldn't go that far. All the cases you cite are of products that definitely classify as substantially better than what they replaced.
Before Gmail took over the market from Hotmail there had been several other companies that failed due to only being slightly better.
Yes you can beat the "first mover", but doing so is hard and requires an almost revolutionizing better product.
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.
Once you'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. 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 the…
It is what we seem to call the 'unknown unknown'. Basically something popped up that was not planned for and now you need to research/fix/qa and shove that in. Even our 'known' bits are always underestimated. Because many people are hopeful and willing to 'try harder'.
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.
” A high level of quality in software is not important unless you're entering an already well-served market. I wish it was.” 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 thing is, 90% of software is “unique”, in the sense that it solves a specific business requirement
I guess it depends how you look at it, but regarding my point it isn’t.
For example most ecom apps/sites are surely ”unique” based on how you described it, but customers have nearly unlimited options/alternatives these days.
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). 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 as…
I really don't like this conclusion. I guess this is why we need financial regulation, because rushing through a buggy payment system so you can make a buck quicker is how customers get their accounts hijacked and identities stolen. Maybe as an early-stage investor or company founder, it makes no difference to you because you'll exit before anything ever hits the fan and the law will never hold you accountable, but y…
==Certain systems need to be robust even if it means businesses might have to earn revenue more slowly. You're not creating value in this case. You're stealing it from your customers.==
Not delivering a feature you promised your customers is also stealing value from them.