6 ms·

Yes and probably more often than you think but it can quite difficult to diagnose from a top down perspective. It usually materializes in costs becoming too gr

Yes and probably more often than you think but it can quite difficult to diagnose from a top down perspective. It usually materializes in costs becoming too great but the underlying cause frequently is a rushed product that eventually costs too much to iterate on because of sloppy underpinnings. Its a delicate balance - you've got to get stuff out quick enough but also stable enough to make sure the next iterations wont become exponentially longer and more costly. Outsourcing, high turnover, constantly changing requirements with unreasonable schedules all can lead to codebases that become too expensive to iterate on when the market demands more. Sometimes the only way out is to approach a complete rewrite which is usually a risky proposition. Many times poorly coded products from the outside can have correlated symptoms of poor performance, bugginess, and slow feature development which are the cited reasons users may abandon the product.

cmorgan8506 14y ago
Do you think "over-engineering" could be a contributor to an unmaintainable code base? Also, do you think TDD is key to faster/cleaner iterations?
- calbear98 14y ago
  Yes, absolutely. I had an experience where the design was dictated by an architect who cared more about the theoretical and having UML diagrams looking nice than about actual business requirements and having the code be lean, clean, simple and efficient. TDD and also code analysis tools can help highlight what you actually need and what you don't. The converse is true too, if you under-engineer you run the risk of not easily being able to scale up to new requirements. Over-engineering creates an albatross where you'll fall under your own weight (too much code, slows down development, possibly bad performance, harder to debug). Under-engineering creates a house of cards that is fragile (more buggy, code gets duplicated and patched on, frustrating to work on, hard to refactor).

cmorgan8506 14y ago

Do you think "over-engineering" could be a contributor to an unmaintainable code base? Also, do you think TDD is key to faster/cleaner iterations?

calbear98 14y ago
Yes, absolutely. I had an experience where the design was dictated by an architect who cared more about the theoretical and having UML diagrams looking nice than about actual business requirements and having the code be lean, clean, simple and efficient. TDD and also code analysis tools can help highlight what you actually need and what you don't. The converse is true too, if you under-engineer you run the risk of not easily being able to scale up to new requirements. Over-engineering creates an albatross where you'll fall under your own weight (too much code, slows down development, possibly bad performance, harder to debug). Under-engineering creates a house of cards that is fragile (more buggy, code gets duplicated and patched on, frustrating to work on, hard to refactor).