81–90 of 180 posts
In general, in my experience, the software can go wrong due to humans being present in the process.
There are mainly 3 types of humans: engineers, product people, customers (clients).
These 3 types of people sometimes lose track of what is really important in terms of features and engineering.
Overengineering and overfeatures kill time to market.
Keep it simple.
Earlier quoted context omitted.
If that were true, it wouldn't take long to build from scratch a functionally identical clone of an existing application. Yet it does. The conclusion is that the tools to build software from a known specification to working code are sub-optimal.
That's like saying a Ford F150 is functionally identical to a Ford Model A because they are both cars. The specific implementation under the hood requires a lot of work. And very rarely do people ever make functionally identical clones without massive refactoring to allow for extensibility.
"people don't make functionally identical clones"
"massive refactoring to allow for extensibility"
You're enumerating the factors that make my point true. Those are some of the reasons why building software takes a lot even if you know exactly what it is supposed to do.
You can compound that to the problem of figuring out what the software should do, which classic IDEs are also bad at. Online collaboration and prototyping tools that put the program in front of stakeholders early; they're like car makers' focus groups that were used to design cars tailored to a target demographic group.
Earlier quoted context omitted.
If that were true, it wouldn't take long to build from scratch a functionally identical clone of an existing application. Yet it does. The conclusion is that the tools to build software from a known specification to working code are sub-optimal.
I don’t want to sound smartass but building an identical clone of an existing application is very fast and often totally automated. That’s what your compiler chain does.
Earlier quoted context omitted.
Totally agree. Move fast and break things? Let’s not. Let’s build carefully and methodically. Teach others how to build quality software. Stop regurgitating what you watch on YouTube 4 hour course. I’ve seen horrific, I mean absolutely bottom of the barrel code being taught to others. Especially in JS community - yes, I’m picking at you guys again. When teaching goes to shit, you’re breeding and propagating, institut…
Move fast and break things itself doesn't imply you shouldn't go back to patch it up and make it cleaner. People should be moving fast so they don't end up in endless discussions regarding or spend too much time on creating a foundation for a solution that doesn't work, and to inhibit perfectionism. People should also be transitioning from "make it work" to "make it good" once it works, prior to delivering or finaliz…
Lol :-D. You haven’t worked in a shop, have you?
Nor is there, in my opinion, widely distributed recognition of this within the industry. There still exists a lack of formalized design methodology enabling to processes to flow through iteratively from ideation, to prototyping, to production. Costs and time taken snowball as a result and project failure rates remain high compared to other engineering disciplines.
I think the high profit payoffs and normative structures due to distribution costs being marginal contribute to the stickiness of this comfy buy rickety state of affairs.
Earlier quoted context omitted.
If that were true, it wouldn't take long to build from scratch a functionally identical clone of an existing application. Yet it does. The conclusion is that the tools to build software from a known specification to working code are sub-optimal.
I don’t want to sound smartass but building an identical clone of an existing application is very fast and often totally automated. That’s what your compiler chain does.
Software takes a long time to build because it's always new. That is, software is trivially copy-able, so there is no reason to spend effort duplicating any software that already exists. (Legal reasons and "not-invented-here" syndrome notwithstanding.) This is a huge different from how the "real" world works, where almost all of the work involved in building, say, a car, is actually just the work of assembling identi…
And yet it feels like authentication and authorization code need to be rewritten for every application.
Earlier quoted context omitted.
If that were true, it wouldn't take long to build from scratch a functionally identical clone of an existing application. Yet it does. The conclusion is that the tools to build software from a known specification to working code are sub-optimal.
I don’t want to sound smartass but building an identical clone of an existing application is very fast and often totally automated. That’s what your compiler chain does.