TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Ask HN: Reasons why software projects get ugly

2 pointsby quazaralmost 7 years ago
I&#x27;m interested in your opinions on why bigger projects seem to inevitably get messy.<p>Is it changing requirements, codebase getting too big to fit in one person&#x27;s mind, lack of communication between developers? Maybe features of a particular language in use?<p>What&#x27;s your experience?

2 comments

Mtiniealmost 7 years ago
It&#x27;s all of those things, especially when paired with many business&#x27; myopic desire to enforce arbitrary delivery deadlines, especially during the fundamental scope framing period.<p>Once a project has set the precedent, early, important decisions are made with an eye on the &quot;easiest&quot; route from A -&gt; B, rather than decided with an eye on building a stable base to work from. This does not mean all decisions are made to build the most extensible, adaptive codebase possible--as this in itself can lead to massively complex, abstracted, and messy projects--rather to understand _why_ the project&#x27;s requirements are what they are and then to select what aspects are (relatively) safe to take short-cuts in versus what absolutely must be bullet-proof and done correctly.<p>You rightfully wouldn&#x27;t decide to build your own car without wheels, if your goal was to use it to get to places, but I&#x27;m constantly astounded by the number of commercial software projects which forgo major security items, back-end administration and monitoring tools, and end-user support resources, in an effort to &quot;release by the end of May&quot;. You don&#x27;t need to have a massively parallel, fully-enabled telemetry, and over-built redundant server farm for v1, but you should have an idea of how your v1 product will eventually become your v10 product.<p>Spend more time as a team thinking and collaborating on the design to reach a shared understanding of what and why you are building, and you&#x27;ll find that in all but the most unique case your development is significantly faster (and with less re-work) once it begins. The people using your software will thank you for it.
asdfman123almost 7 years ago
It&#x27;s changing requirements without taking time to clean up technical debt.<p>Also, poor design decisions early on can really influence things later.