Even though this article resonates with me, I think it portrays everything much too glamorous. I wish the subjects described were the only source of problems. I

Even though this article resonates with me, I think it portrays everything much too glamorous. I wish the subjects described were the only source of problems. I suspect that in reality, most mistakes have quite 'simple' causes. Some observations: - By putting an abstraction layer in between, people visually creating applications, the problem is pushed to the layer below and new problems will be introduced. - Supporting intricate, bespoke functionality in a visual environment will be incredibly hard and error-prone. - If you have trouble thinking about how your software will run, you should run it on a computer instead of your brain. I.e. continuous builds, debuggers and sandboxes. - Pushing for deadlines and using prototypes as production software is part of this. - Those millions of lines of codes usually include a number of Linux kernels. - Before getting to all the fancy stuff and visions about the future, why not first: --- Get all software unit tested / test driven. --- Get all software functional tested / behaviour driven. --- Use domain driven techniques to close the gap between 'reality' and code. --- Create truly comprehensive tests and testing environments for areas that matter.