Another excuse to stay up until 3 AM.

Archive for April, 2011

Smarts vs Skills in the Discipline of Software Development

In a previous life, some of the most senior developers in the company I was working at felt they were smart. They wrote code that worked, and it made them good money. In fact, they felt software developers who couldn’t understand their code weren’t fit to call themselves such, and certainly shouldn’t be working at the same company. What the code actually looked like or how well it was designed made little difference. This left me feeling resentful and frustrated, but not in a good position to argue.

Now, with more experience and authority, I feel like I’m in a place where I can better articulate why that’s not enough. There are plenty of smart people out there who can write clever code that works. But it takes skill to craft code- code that is clean, flexible, easy to maintain and easy to understand. Smart can only take you so far.

Using carpentry as an analogy, I could, with smarts but no real skill, put together a wooden stool to stand on to reach the higher shelves in my kitchen. I could hardly use the word “craft” in this case, since I have no experience with the discipline of carpentry and the skills that are necessary for its mastery. I’m reasonably confident that the stool would last for at least one standing-on, maybe even a few. Maybe it lasts a whole month. Maybe, through trial and error, I build myself a chair and a table. And perhaps for my own use, as rickety as they are, these things that I’ve built are good enough. But they’re not good enough for me to have guests use, much less sell to customers.

Likewise, software development is a discipline that requires the command of skills. This discipline allows us to craft software, not merely slap it together like a few blocks of wood barely held in place by loose nails. And in the end, it’s the mastery of this discipline that truly determines who is fit to be called a software developer.

Of F#’s Units of Measure and Parallel Universes

Functionality like this in a language was news to me, though it’s obviously not new news. Speaking from my small corner of the Java/JVM world, my impression has been that there’s usually little effort expended by the average developer to go and explore terra incognita, especially if it means heading out in the direction of Redmond. That’s something I’ve been guilty of too.

In the Java world, the OOP bubble that some programmers live in is being popped from the outside by the burgeoning popularity of Scala and Clojure, and the great “ah-ha” moment of realizing there’s more than one way to skin a cat is upon many. Yet there’s this other parallel universe that exists—the Common Language Runtime—and in it dwell alien things like LINQ and F#’s units of measure- things that had never occurred to me before. There are even developers at my workplace who use such technologies, but they sit isolated from us, not involved in our agile this and kanban that. Maybe it’s time to talk.

Anyway, it’s obvious that those folks in Redmond are pretty smart. I hope we’re not ignoring them and their ideas just because of the swaying banner of Microsoft above their heads.

10 Myths of “Brownfield” Development

This presentation about 10 myths of “brownfield” development by Josh Graham of ThoughtWorks seemed very relevant to me, considering how often we find ourselves working with legacy code as developers. It’s well worth taking a look at:

Here are the 10 myths with my brief notes:

  1. Brownfield development sux – greenfield development is teh awesum
    With proper resources and sufficient support, great opportunity for renewal.

  2. An OO implementation is slower than a procedural one
    Not with proper domain modeling.

  3. It needs a complete rewrite to scale 100-fold
    Proper domain modeling -> a smaller, manageable object graph -> less need to hit the DB, with immutable value objects enabling safe concurrency and parallelism.

  4. It needs a complete rewrite to perform 99% faster
    Performance testing, business activity monitoring, profiling, etc. make this easier. They leveraged AOP to implement monitoring.

  5. An XP team can’t work concomitantly on the code with Waterfallers
    Good communication between teams enabled teams to work together well.

  6. You can’t complete in 10 months with a team of 10 what a team of 20 can’t complete in 20 months
    In fact, fewer developers meant greatly reduced overhead, greater agility, and greater speed.

  7. This 10-year-old pile of JaBOL won’t be winning any awards
    I.e., Java written procedurally, like Cobol. In fact, the software in question was an extremely successful product, and worth working on.

  8. Those outsourced developers will never get “the Agile”
    Even developers used to “bug-driven development” can be brought into the fold with pairing, TDD, etc., and the relief experienced by dealing with well-crafted code.

  9. DBAs won’t work with the developers to evolve the database
    Devs being proactive in aiding the DBAs mitigates this: pairing with DBAs to refactor the database, helping to write migration scripts, etc.

  10. Architects don’t code
    If the implementation isn’t matching the architecture, then the architecture is of no use. Architects’ involvement in implementation gives them the feedback they need to know that their ideas are actually valid and working.