Another excuse to stay up until 3 AM.


There’s Something about Scala….

I was recently talking to @SeanTAllen about Scala, and we both agreed that there was something about it that made us uneasy. Sean talked about being bothered by it’s “high cognitive load,” but it took us a bit to be able to verbalize why that cognitive load exists. One thing that Sean said that struck me was “There is a lot to like about Scala, but I keep being like ‘why do I have to remember that?’” I think what it really comes down to is lack of elegance.

When a tool or a programming language is elegant, its use and application feels intuitive: you can infer things and makes guesses about how to accomplish things, and those guesses usually turn out to be right. Part of its power comes from making sense in an organized, predictable way. In Scala’s case, however, power seems to come from a grab-bag of features and shortcuts which are mostly there to satisfy the longings of Java developers for greater programming efficiency. But why be a better Java, with all the baggage that entails, when you can be a better language period?

I think Scala is the wrong direction to be taking.

The Double-Edged Sword of Group Ownership

While looking at code reviews the other day, I was struck by some developers’ inaction over various issues with the code base. That got me thinking about the idea of group ownership and how it can perceived by individuals. I think the ideal when a problem occurs is:

Group ownership → we all own it → I also own it → I’ll try to fix it.

But many times that doesn’t seem to happen, and instead I think the following logic is used:

Group ownership → we all own it → people other than me also own it → they can fix it.

Which, of course, isn’t much different than a lack of group ownership in the first place. In the end it seems that merely repeating the mantra of group ownership isn’t enough- what’s really necessary is an understanding of what group ownership actually entails, and the responsibilities developers share as a result.

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.