Agile programming and code abstraction level

During my insignificant life, up to now, I’ve seen many times people writing bad, or really bad, or really really bad code with the excuse of a tight timing or a dead-or-alive deadline to deal with.
It’s the principle that is wrong. If you are one of those, let me tell you why you are a failure yourself. You’re doing it wrong and you probably did since the beginning of your <latest coding adventure>.

At some point in the process, you started trading fast, easy designing and coding in change of less hassles (typical words: “who cares”, “we’re going to use <put-your-favourite-SQL-engine-here or other query language> anyway”, “this code has to do this-and-that, period”, “i’m not planning other features”). The funny part is that you did that with the Devil: you just sold (a part of) your soul to him (see “Bedazzled”, 2000, it’s a funny movie). And we all know that the Devil someday will knock back at your door.

This is not good for your health either. And it’s what the so called “Agile programming”  tries to avoid you. Agile programming, besides its scientific definition and explanation has the “side-effect” of “forcing” (see the quoting) you to write good code, with a good level of abstraction. Given that it warmly welcomes people wanting to throw code away for a rewrite (refactoring), keeping your architecture fresh over time.

Thanks to my dedication in trying to keep the whole Entropy (the package manager I wrote for Sabayon) architecture as much clean as possible (it’s still a “one-man-army” project), today I can happily break the underlying SQLite3 db schema without worrying of possible higher level consequences and, more important than anything else: keeping the holy backward compatibility. Also thanks to Agile programming (which is something nobody can realize by watching a plain git log).

About lxnay

the creator of Sabayon Linux, Entropy Package Manager {Eit, Equo, Rigo}, Molecule release media buildsystem, Matter Portage buildbot/tinderbox and only God knows what else...

4 responses to “Agile programming and code abstraction level

  1. ferringb

    Mildly pedantic, but your example of why agile is great is actually just an example of encapsulation/modularity (most definitely not something that is soley agile’s domain, and in my experience something that can be actively screwed with by scrum’s if they’re not ran w/ a long term view).

    Just saying.

  2. I didn’t say that the example IS the only reason why agile is great (which includes scrum, for sure), I’m just saying that these dev. methodologies help people focusing on quality and simplicity, also avoiding burnout, why not. I wanted to keep the “scrum” thing for another blog post😉

  3. 4m

    “you are a failure yourself” sounds a bit harsh….

    Reasons for inept coding habits can be manifold. What i often see – in many areas – is a false sense of realism, where people don’t realise that they in fact are being pessimistic, which may lead to reasonings like: “I know my limits. My code will never win me a Nobel prize. Besides, I need money to pay my bills.” What they then don’t see is that such thinking leads to them not working at their full capacity.

  4. I might agree, but I am sick of tolerating bad code that other people do. 50% of my daily time on FLOSS is spent on fixing what other people broke!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

hello, twitter

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 585 other followers

del.icio.us

%d bloggers like this: