After almost 10 years working in corporations and in the government, I can't help but think that Dijkstra's call for quality rings truer than ever. It's appaling the amount of projects that get killed not only because they were poorly executed but also because they were completely useless in the first place.
In this day and age we live in a kind of stupor that we have to keep the wheel of economy spinning no matter what and that as long as someone is paying we have to keep sh*tting lines of code for perpetually late projects. It's like we're inefficient on purpose. Look at the shitshow that the SCRUM method is for instance. We are purposefully distancing software development from any kind of rigorous method, it's a real tragedy.
Scrum is not an acronym, there's no need to write it in all caps.
Scrum is not intended to remove rigour from development. It acknowledges that people (the client) have no clue what they want (they're no Mozart), and that it's up to the development mean to help them figure it out. Ideally converging on something that the client wants, and works well.
Sure, plenty of projects fail for a variety of reasons. And sure, scrum (or agile in general) isn't perfect. But it's the best tool in our toolbox at the moment.
You, and all those other folks who like to tilt at the scrum windmill, are more than welcome to propose something that works as well as (or better than) scrum without the downsides. But so far, it's been crickets.
IMO there are three big issues: clients don't understand software development, and management doesn't understand software development, and software developers neither understand clients nor management.
If you think that it's the role of a developer to figure out what a client wants, then well... We have completely divergent views of how the the process should be. A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product.
It's not that scrum is not perfect, scrum is an absolute garbage that unfortunately today fits very well with the micromanaging hunger of managers, no method is better than scrum.
> A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product.
That's a sad view. Reminds me of a couple past managers I've had who thought that software developers were assembly line workers.
US culture note: The cultural expectation for assembly line workers here is that they "shut up and color", it's the job of the managers and engineers to do the thinking. That is, even if an assembly line worker can see that something is wrong, it's not their job to point it out or fix it. They are disempowered in this culture.
What's sad about your view is you similarly want to disempower developers. You don't want them to have input into what they're making, you just want them to shut up and code. According to you the specification is, what, always given to the developers without their input? So if the specification is non-viable they should just accept it and sit in their corners making nonsense?
I'm not saying that developers should ideally be drones who have no say on anything. I'm just calling bullshit in the ADHD-fueled development of nowadays where people are not even sure about what the final product should look like and put on the shoulders of the developers the workload of dealing with the ineptness of the clients and the managers.
Scrum nowadays is essentially a tool for micromanagement, that's why managers love it and developers hate it. Dailys are completely useless and breaking the development of complex projects in 2 weeks sprints is outright harmful.
> calling bullshit in the ADHD-fueled development of nowadays where people are not even sure about what the final product should look like
Sigh. Of course people aren't sure about what a final product should look like. It's easy enough for something small, but once something gets big, how the hell are people expected to know how everything will work up front?
> Scrum nowadays is essentially a tool for micromanagement, that's why managers love it and developers hate it. Dailys are completely useless and breaking the development of complex projects in 2 weeks sprints is outright harmful.
Sure, some managers love scrum, and some developers hate it. But it's not a tool for micromanagent. It's a tool for course corrections in the face of reality.
I personally find dailies to be very useful, especially in a distributed team. It's an efficient way of figuring out what's up and making sure all noses are pointed in the same direction.
No managers are involved in any of my day-to-day scrum ceremonies.
If your manager hits you with a hammer, you might want to consider that your manager is an arse instead of blaming the hammer. When a tool doesn't work for you, sometimes it's not the tool that's to blame, but the larger context in which the tool is being used.
> A software developer should develop for a specification
Really? And where does this specification come from? Presumably from a bunch of analysts? Who then write a big fat document? Which is then handed over to developers, who then groan because it is incomplete, unclear, unusable, or unrealistic? This sounds an awful lot like the waterfall of yore which turned out not to be all that great.
> he or she should not be there to entertain clients in a game of creating a product
The client tends to pay people with the hopes of getting a working product. It should absolutely be the developer's job to ensure that they get it. Even if that means -- shudder at the thought -- talking to them.
Pedantry on my part, but would you say that a non-existent unicorn weigh some amount "None"? That'd be strange to me, and "no amount" would describe such a situation.
That hypothetical has very little to do with the situation at hand. Badd software clearly exists and it is possible to talk about how much mathematics went in it. If no mathematics went in that's still an inidication of 'how much' and therefore is an amount.
"A non-existent amount of mathematics" -- which the joke could have been interpreted as implying -- is not zero mathematics: that would be an existent amount.
Another place these semantics arise is in talk about probability and possibility, wherein the possible can have zero probability (e.g. any specific value in a continuous probability distribution), but the impossible cannot have a zero probability because by definition it is outside the set of "possible events" (measure theoretically). Both make little intuitive sense.
This rings true in my experience too. It isn't even artisanal code lacking an end user, its garbage code that barely works which no-one wants. Luckily I've spent most of my time in the start-up space where things working is a more existential concern, and the sort of thing mentioned above is less of a problem.
In this day and age we live in a kind of stupor that we have to keep the wheel of economy spinning no matter what and that as long as someone is paying we have to keep sh*tting lines of code for perpetually late projects. It's like we're inefficient on purpose. Look at the shitshow that the SCRUM method is for instance. We are purposefully distancing software development from any kind of rigorous method, it's a real tragedy.