Sunday, March 24, 2013

Organization

As
Benjamin Franklin pointed out there are two parts to organization. The
first is that absolute everything needs to fit somewhere. With software
this really translates to having a solid 'reason' for every little bit
in the system, be it config files, methods, data etc. and a reason for
its location. It all needs its place, and often for that it also needs
some level of categorization. "It doesn't matter" is synonymous with
"it's not organized".

This
includes names, conventions, even coding styles. Everything. Each tiny
piece of work, each little change should all have its place. It should
all have a reason for being where it is, as it is.

The
second half of the quote is just as important. What's the point of
having an organizational scheme if its not being used. As new things are
added, they need to be added into their place. Sometimes it’s clear
where they belong, but often times it hasn't been explicitly documented.
Assuming that lack of documentation equates to lack of organization
(and as such it is a free for all) is a common failing amongst
inexperienced coders. Things can be organized with having an
accompanying manual.

Failing
to keep a development project organized is the beginning of the end.
Disorganization is probably the worst aspect of technical debt because
it is a direct path into various forms of spaghetti. And spaghetti is a
quagmire for time, either to fix bugs or to extend out the
functionality.

Part
of software development culture over the last couple of decades has
been a strong desire for 'freedom'. Freedom is great, but used
improperly it just becomes an excuse for creating disorganization. For
instance, utilizing the full freedom to create a new screen in a much
fancier way than the existing ones is really just breaking the
organization of what is already there. It's like helping someone dry the
dishes in their kitchen, but then insisting on placing the clean stuff
in any other location than where it actually belongs. It isn't really
helpful is it?

It's
true that in some regards a well-organized existing development project
is a boring one. If the work isn't exceeding the existing
organizational bounds then it can really just fit in like all the other
pieces. But success in development doesn't come from making any one
small piece of the system great, it's an all or nothing deal. The system
is only as good as its crappiest screen or stupidest functionality.
Thus changes to enhance it or its organization can't be selective. The
whole thing needs to be fixed or it’s actually just making it worse.

If
you're evaluating an existing development project, disorganization is
easily the best indicator of the future. A small project can get away
with disorganization, but anything larger absolutely needs organization to
survive. If it is lacking or failing, then the whole effort is in deep
trouble.