Auto-translation used

If there is no visibility of where the project is going, it is almost guaranteed to be poorly written.

Without understanding the endpoint, one of two things almost always happens.:

Overengineering — they do it "for growth", lay down complex architectures that will never be needed. This is bad for business: it takes longer, is more expensive, and is unnecessarily difficult.

Underengineering is done "on the knee", without architecture and a foundation for development. This is bad for development: difficult support, chaos in the code, expensive revision.

And here's the paradox: the second case is worse for developers, but easier for businesses.

Why? Because:

— A project from scratch is rarely technically evaluated — the customer does not know that "good code" is cheaper in the future.

— And no one pays much for minor edits, even if it takes 10 times longer to deal with the project than to solve the problem itself.

Therefore, vision is not a luxury, but a necessity. Even a basic roadmap greatly improves the quality of architecture and saves money.

And what was your experience — did you have to work in projects "blindly"?

Comments 8

Login to leave a comment