
Ask HN: Reasons why software projects get ugly - quazar
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?
======
Mtinie
It's all of those things, especially when paired with many business' myopic
desire to enforce arbitrary delivery deadlines, especially during the
fundamental scope framing period.

Once a project has set the precedent, early, important decisions are made with
an eye on the "easiest" route from A -> 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'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.

You rightfully wouldn't decide to build your own car without wheels, if your
goal was to use it to get to places, but I'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 "release by the end of May". You don'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.

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'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.

------
asdfman123
It's changing requirements without taking time to clean up technical debt.

Also, poor design decisions early on can really influence things later.

