To play Devil’s advocate: that’s 2 months a customer went without being able to use that feature. What could you or the company have learned if you shipped an earlier version and measured how people used it? Was your feeling of control and happiness worth the business information of not having that feature in the wild for 2 months?

The communication and coordination overhead of four or five developers working together is non-neglible on top of that if any part had to be reworked that also would have involved overhead between multiple developers. No matter how well you spec something out, there are always the unknowns - i.e. I forgot about this piece of business logic based on a checkbox on the front end which is going to cause a boolean to be passed in the model that’s going to affect all four services and a database table. Now I need to either communicate with all of the developers, or do it myself and dig through code I am not familiar with. In this case, I just make all six changes myself, do a quick test and commit the code and update the docs.

Then all four developers would have had to coordinate with the Devops guy.

This is all getting into “Mythical Man Month” territory.

Instead of me trying to explain it, I might as well crib the explanation from Wikipedia.

Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.

Four equally qualified people should be able to deliver more features in the same amount of time working independently than four people working together.

The solution to this problem is to solicit user feedback all the time. As in, the moment you get your code kinda sorta working you get some feedback from the ultimate end users (e.g. NOT the product manager, LOL)...

"This rough implementation is how I (we) envision this feature working. What do you think?"

"We've got the feature working well but it requires non-trivial back end changes. Would you be willing to wait or will you be satisfied if it works but only in a very manual way until we get the back end changes in place?"

Week 2 after release: "The feature is live... What do you think? How is it working?"

These are conversations the developers should be having with the end users. Regularly! It's when developers only ever talk to their boss and/or the project manager that pushes development into the anti-user zone.

Good luck getting the customer to provide feedback on a <2 week cycle. Ime. customer feedback and/or approval is a serious dev bottleneck.

That is also feedback. Having unresponsive customers is a bad sign, often suggesting that maybe they're not as interested in the product as the smiles the hyper-gregarious sales team receives would suggest.

It’s not always about customer feedback when implementing functionality. For instance, take the rules governing rail car maintenance.

https://www.railinc.com/rportal/documents/18/260641/Guidefor...

The software for it has to work. There will be months of work implementing the rules engine before you have anything to show the customer besides a mock-up..

You won’t really need two week sprints to get feedback from customers. It either implements all of the rules or it doesn’t. I can imagine the same happening for tax software.

That’s taking a strictly algorithmic approach, and assumes the rules are equally understood by all parties and have no inconsistencies or undefined states. And as an example, I happen to know TaxCycle is unusually responsive to customer feedback on releases and offers early previews. Here’s a list of improvements from 2017 feedback: https://www.taxcycle.com/News/Your-feedback-becomes-features...

Your customer might not have the manpower to test your product all the time. They're presumably already spending a lot of money on you, they might not want to spend an extra headcount just for testing your work. They might feel that that's your job.

Happens all the time, and usually ends up in disaster. Not willing to test means that don't know or care, and you are throwing darts blindfolded hoping to luck into what they imagine they want. I've been on projects customer would say, "I don't need to see it, I know you're going to blow us away!" You do your best but it never ended well.

The best is when the team delivers 100% what was specified on the Jira items, do the demo after several failed attempts to get feedback and then they state that "it is nice but not really what we want".

> They might feel that that's your job.

If a customer isn't committed to the project, then I'd worry about committing to it as well. Even if the contract guaranteed I'll get paid, there are few things as demoralising as a project falling over because, once push came to shove, the customer didn't even have the manpower to deploy your product. Those are usually the same people who would do the evaluation, so with my experience, as an employee, if they're not there, I'm going to look for a project where they are — regardless of how confident sales might be.

You must have much better end users than I have. My users seem completely incapable of looking at a half finished, sort of working proof of concept and not get bogged down focusing on everything that obviously doesn't work. I definitely agree that you should talk to your end users all the time, and ideally observe them working and using your product (or your competitors product) to the extent it's possible, but I've never had much luck discussing rickety proof of concepts with them.

The problem with all the devs talking to users is that many of them are bad at it and have no desire to do it or improve at it. So that means you are either very, very limited in who you hire or you have to have some devs that don’t talk to the users.

> a customer went without being able to use that feature.

Well, by definition, a feature that takes 2 months to build takes 2 months to build. Shipping part of the feature early doesn't provide feedback for the finished product. It provides feedback for the incomplete feature. How valuable is that feature?

In addition to that,a feature that takes 2 months to build will take longer if you are releasing multiple sub versions. You have to account for actually making it production ready, and releasing it, and handling errors and feedback.

This is why experience matter. Was your feeling of control and happiness worth shipping half-finished, substandard product to your customers?

And in the real world, you often go through all of the ceremony of a “release” but it isn’t put in production until it’s complete anyway. Until then, the feature is just on a UAT server and the code is officially “in production” but it’s behind a feature flag.

To play devil's advocate.

Other work can be assigned so in two months the customer gets the entire website. If they did it the other way every two weeks something would be finished but at the end they need to rewrite the backend adding an addional months because they didn't have the chance to look ahead and see that module 1 and 2 can't run at the same time.

Which is actually very relevant to the project that I’m referring to. All four services were database intensive. They all worked perfectly independently. But when messages started at service 1, did some database work and put a message in the queue to kick off the next process and so on. When all four were running at the same time processing messages, the database screamed and made the website unresponsive.

It took me longer to tune performance than to write the code. Can you imagine four developers working together tweaking code, queries, indexes, number of simultaneous threads, etc?

This is an "ideal" which I would argue almost never happens in the real world.

exactly !! if a feature is worth having... its usually value in having it in one week rather than 3.. sooner is better... scrum does not allow this

Not if that early feature is broken and doesn't work. Then the conventional wisdom will quickly become "Don't use feature X, it's broken" and you're going to have to spend a lot of time re-educating your user once you've actually gotten around to fixing it (assuming you actually get around to fixing it and aren't pulled away to do something more 'important')

On the flip side, this has a cost of creating siloing/low bus factor, so if you were to ever get in an accident that took you out, or you left the company, the company would be potentially completely screwed.

I’ve learned the hard way from years of experience that if I am the only person that knows a system, that means I will be stuck on it forever and can’t move on to the new shiny.

When I was a team lead, I made it part of the “definition of done” that you had to have documentation and knowledge sharing. Now, I still have both an overview of my proposed architecture before I start just to make sure I didn’t miss anything, Visio diagrams,Powerpoint slides, wiki documentation, an “architecture review”, etc. I hold myself to the same standards I held anyone on the team to.

From a career development standpoint, software developers are a dime a dozen. It’s the people who know how to communicate effectively are the ones that get ahead.