3 ms·
The agile manifesto makes no sense. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. What if t
by 0xbadcafebee 4y ago
The agile manifesto makes no sense.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
What if the software requires a lot more work before it becomes valuable? What if continuous effort isn't sustainable or there aren't many features required? What if this just leads to software development for its own sake?
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
What if change is so constant that you never ship a single working feature? Or every time you change, it breaks the user experience? Or you simply can't keep pace with how much of the app is changing and are stuck in tech debt hell?
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
What if the software is running in a car? A plane? A bank? A pacemaker? A power plant?
On and on it goes. Stupid overgeneralizing proclamations that are trivially debunked, yet passed off as some kind of grand scheme to solve all that ails making software products.
You know what software is? Materials. Materials are used in our everyday lives, from textiles to plastics, structural steel to paper. You build a machine to grow the cotton, then a machine to harvest the cotton, then a machine to spin it, then a machine to weave it, then a machine to dye it, then a machine to cut it into a pattern, then a machine to stitch a logo into it, then a machine to make the plastic bag it's packaged in, then a machine to ship it, and so on.
All of those materials and machines are created by people, and then used by people. They break down, they need maintenance, they get replaced, and they get used. The significant difference is, most of them aren't made so only Gardening Machine A can be used with Weaving Machine B to go into Dying Machine C and be used on Cutting Machine D, etc.
Software is written in a little box, and it's very fragile, like the works in a watch. It's not durable and universal. It's delicate and tiny and intricate, and made to fit. We spend all our time fretting and niggling and poking and prodding and teasing the software, and wonder why we can't ever estimate how long it takes to make something. But it's because we keep making new watch springs, each one slightly different than the last one. Of course there's no consistency; we're not making things consistent!
The software industry is like an industry of teenage art school students trying to build hospitals. Quite expensive and complicated, but made worse by a whole bunch of "creatives" constantly changing things to fit some custom ad-hoc sculpture sitting on a platform of marbles. The people who are smart enough to make it won't do it in a way that's repeatable; the people who have the money refuse to contribute their work to some sort of general industry-wide commons of resources; and the people who organize them just want to get anything done, so who cares about rigor or process or efficiency or uniformity, just shove some shit out the door so I can collect a paycheck.
At least cargo cults deliver a plane every so often.
- randomdata 4y ago> What if the software requires a lot more work before it becomes valuable? Then you haven't broken the problem into small enough pieces. You're not trying to deliver a finished product, only something that can allow vested interests to gain a better picture of what is being built, enabling them to provide feedback early. If you are building ChatGPT and deliver a simple speaker amplifier that will be used to allow the humanoid robot to be able to provide sound, someone can say "That's neat, but how about a text field in a web browser instead?" If you wait years until the entire humanoid robot is working, you've wasted all that time before getting the feedback that all you really needed was a text field in a web browser. > What if the software is running in a car? A plane? A bank? A pacemaker? A power plant? What if? If you are working on developing software for a car, you don't think you won't have a car to install it on to allow the vested parties to see it? Or, at very least, some kind of car simulator that achieves the same effect?
- tguvot 4y ago>Then you haven't broken the problem into small enough pieces. You're not trying to deliver a finished product, only something that can allow vested interests to gain a better picture of what is being built, enabling them to provide feedback early. This is called roadmap. Client provide feedback to roadmap. There can be few iterations. Interests of multiple clients are taken into consideration. Based on roadmap products are build. I worked in companies that made telecom software. The kind that manages both business processes and operational aspects. There are no "smaller pieces" that can be delivered to show process. There are also no people who will care about it on side of telecoms, because they know what will be delivered. Those systems are upgraded once, maybe twice a year after very long verification processes. They influence how things are working for hundreds of millions of people. Sometimes stuff that life can depend on, like 911 calls for example. I also worked in multiple companies that made telecom network hardware and various network security appliances. It's same story. Clients know roadmap. Roadmap implemented. If this is new product, maybe a few key clients will get some alpha/beta hardware to start working on integration into their systems. Besides this, people on client side are busy with their day to day work and don't have time or interest to provide continuous feedback, because they know scope of product to be delivered.