3 ms·

> That last part is actually the easiest The last part is wrong, unless it's purely greenfield. Instead, you first need to read and then modify existing code

> That last part is actually the easiest The last part is wrong, unless it's purely greenfield. Instead, you first need to read and then modify existing code and ensure it can later be still understood and easily/safely changed by whoever works on it. That is the hard part that is totally missed here.

jongjong 1y ago
That's correct. Writing code isn't like building a house. It's not like you just add one brick on top of another and every brick you added stays in its place forever. It's much more complex. As requirements change, you may have to pull out some bricks, sometimes redo entire floors. I've worked with low-code platforms and also built my own low-code platform which allows me to assemble CRUD apps quickly and avoid/bypass a huge range of possible bugs, but even then, it's still not quite like laying bricks... What happens is that the bottleneck becomes UX decision-fatigue. Translating complex business requirements into a working product is rife with conflicts at the level of requirements engineering and UX. You can attain a certain level of software complexity much faster but the requirements also evolve faster to the point where you're constantly thinking about how to make different parts of the UX work well together in a way that's not confusing.