As a Manager: What I value in developers

There are many traits a good developer has. Focus. Sense of Quality. Interest in what he does. Knowledge of programming languages and skills in software development. An opinion. Team player. Update see comments: Being creative and innovative. Propose ideas.

But the things I most value are professionalism and getting things done.

Those are similar to the one Fog Creek and Joel Spolsky find important. Joel on Software values:

First of all, the #1 cardinal criteria for getting hired at Fog Creek:
Smart, and
Gets Things Done.

Why professionalism? There is not enough sense of a profession on our industry. We do need more professionalism to be taken serious by others. By our customers. Noone would argue with an account about his practices, or with a surgeon about his. The only high-profile person caring about professionalism seems to be Uncle Bob. This can be felt in many of his arguments:

Look, TDD is not my religion, it is one of my disciplines. It’s like dual entry bookkeeping for accountants, or sterile procedure for surgeons. Professionals adopt such disciplines because they understand the theory behind them, and have directly experienced the benefits of using them.

Professionalism is about not doing things that are stupid. Not cutting corners. Have pride in your work and write clean code. Get the software development industry and your job to a level where surgeons and accountants have been for centuries.

Why gettings things done? In the end, what counts is money earned. Everything else is a proxy. If you want to get paid, your company needs to earn money. Honour deadlines. Getting things done means no gold plating. It means understanding the necessity for business to get features to their customers. Suppressing the urge to develop a framework out of everything, to develop frameworks first before you really know what is needed. Write frameworks when it helps you getting things done. To dive into large refactorings at the wrong time.

You need to strike a balance between both. Too much professionalism and your customers will be annoyed. As will be your boss and your colleagues. It means you will make professionalism and end in itself and forget about getting things done. Too big a focus on getting things done will make you cut corners. Write bad code. Being not professional.

Your company needs to support you with both - a environment for professionalism and letting you getting things done. Many companies don't. Some focus too much on professionalism, some focus too much on getting things done. What if your environment doesn't support you? Joel writes in another article about you getting things done:

A lot can be done to improve the project just by one person doing it. Don't have a daily build server? Make one. Set your own machine up with a scheduled job to make builds at night and send out email results. Does it take too many steps to make the build? Write the makefile. Nobody does usability tests?

And most managers will value you highly when you get things done.

What about you, what do you value? I'd like to hear in the comments.

What is Trans-Scrum?

There is the well established notion of what Scrum-But is. There is also a clear definition of Scrum - although people still argue if someone is doing Scrum or his process is only Scrumish. But more or less, territory is known. At least in the two dimensions, black and white about Scrum or not-Scrum.

After many years of Scrum people have inspected and adapted for many iterations. Additionally the current increase in lean and Kanban adoption engulfs many Scrum projects. Developers are using Scrum together with XP and some believe you are more successfully and productive when using XP practices together with Scrum.

There is no term describing these efforts. People who have moved beyond Scrum-by-the-book, adapted lean values, moved to flow and continuous deployments and who have perhaps dropped some of their Scrum practices (LINK mein blog) like iteration reviews, what should they call their process? Strong Scrum enthusiasts would say don't call it Scrum at all. Call your process agile or lean. But with iterations, a ScrumMaster, ProductOwner and story point estimation, this sounds too weak and doesn't reflect the still strong Scrum base of the practice.

I suggest calling these processes Trans-Scrum. This term is for people who still believe in Scrum and have adopted Scrum successfully, not those who dropped the effort for whatever reason (and this is fine!). As long as Scrum and the values of Scrum are the base of your process, you're Trans-Scrum.

This would help communication between people, talking about processes and sharing knowledge and wisdom. I often struggle expressing myself what we do here. This is difficult because when you, as a Trans-Scrumer, tell people you do Scrum they get the wrong impression. If you tell them you don't do Scrum, they also get the wrong impression. Even more if you tell them - who would? - you do Scrum-But? [1]

Only when you move beyond that, what some surely will as they adapt even more to their context, start calling your process something else.

What would you call this process? Scrum 2.0? Scrum++?

[1] The difference between Scrum-But and Trans-Scrum is, in the Toyota sense, that you've done practices in Trans-Scrum and after learning you've dropped them as not necessary. While with Scrum-But you don't do these practices from the start because you think they don't work for you.

Is this functional programming?

Recently I've read a blog post by Keith Dahlby. It was titled "Is Functional Abstraction Too Clever?". The title sounded more rhetoric because clearly Keith was very satisfied with the code he presented.

But it got me thinking again. After some time with Lisp at university, some Haskell and some functional thinking in Ruby, I'm deep into Scala for some months. I've written some functional code before in Java, but I'm using much more with Scala now. Many examples are mostly thinking and syntactic sugar to me, not something I can put a finger on: this is functional.

Haskell examples clearly are more functional - how so? - and some blog authors give very nice functional solutions. Some blog posts by Raganwald and Debasish gave me great insights into functional composability. But many examples of people new to functional programming do not look functional to me.

Keith says about functional programming:

To me, this is the value proposition of functional programming. By expressing the algorithm in terms of common operations, we're able to spend more time thinking about the problem than the details of the solution.

Let's take a look at his code:

static int[] GetSlots(int slots, int max)
    return new Random().Values(1, max)
                       .Take(slots - 1)
                       .Append(0, max)
                       .OrderBy(i => i)
                       .Pairwise((x, y) => y - x)

Looks more like a filter pipeline than functional programming. Especially compared for example to the things Apocalisp does with functional programming. Years ago I wrote a rendering pipeline, before the functional hype, and it was just a collection of Filter objects which filtered and transformed input into output. There were many users, and no-one thought of it as "functional". Keith goes on:

A similar change in an imperative implementation would almost certainly have been more involved and prone to error.

The example is written in C# so it supports closures neatly, transformed to Java it might look like this (the generics are not totally correct, I'm spoiled by Scala):

static int[] getSlots(int slots, int max) {
  return new Random()
      .take(slots - 1)
      .append(0, max)
      .orderBy(new Order[int]() { public int by(int i) { return i })
      .pairwise(new Folder[int]() { public int fold(int x, int y) { return y - x })

More involved? More prone to error? Not so sure. Someone with an OO background would righteously say: Sure this is OO. Method chaining and objects.

As we all know, Java is not a functional programming language, but an object oriented one. There isn't much difference here, some shorter code, some syntactic sugar for creating functions. The only difference between object oriented and functional being that OO is more noisy? Is OO as superset of FP? The line blurs even more with Functional Java. Is functional not only a way of thinking? Immutable, side effect free, composable code blocks?

Is this example functional? What is functional? Your view would be appreciated, especially if you're one of the usual suspects.

ORMs are a thing of the past

ORMs are a thing of the past. Hold your anger! I always thought ORMs were the next best thing after sliced bread. I was so convinced about ORMs that I wrote some of them on my own in Ruby and Java - not very good, mind you - during the 90s. Later I switched to commercial ones and settled with Hibernate and JPA for many projects. But after years of usage and seeing developers on my teams work with Hibernate, I'm no longer sure it is a good thing.

Beware: This is a non-conformist post. I'm also one of the very few people who think JPA/Hibernate annotations are bad for your domain classes. Keep this in mind while reading further.

Problems with ORMs

They are a delusion. They help you getting up to speed fast and prevent you from writing noisy boiler code. Over time they will pose problems, those problems becoming bigger than the speed you've gained. The biggest two:

  1. ORMs are most problematic due to performance concerns. Many developers I've met never look into Hibernate SQL logs to see what queries are generated, and how many of them. Should they ever look in the SQL which is executed, their eyes will pop up. Mine did. Nearly.
    As Aldo wrote in "A Farewell to ORMs"

    Whether or not the magical plumbing is worthwhile depends largely on how often the abstraction breaks down. The ORM approach does so frequently. Yes, I can use an ORM and think at the object level in the common case, but whenever I need to do anything remotely complicated - optimising a query, say - I'm back in the land of tables and foreign keys. In the end, the structure of data is something fundamental that can't be simplified or abstracted away. The ORM doesn't resolve the impedance mismatch, it just postpones it.

  2. Leaky abstractions. You think the ORM works but it doesn't. It throws exceptions to you. Lazy initialization exceptions in Hibernate popping up in the most unfortunate circumstances because you made wrong assumptions about sessions, scope and flow. These are hard to find and often harder to fix.

But these are not the main reasons for the phasing out of ORMs over the next years. Additionally ORMs may hinder future development and not be a safe investment because they lose their grip on enterprise development with the advent of NoSQL data stores. Polyglot persistence will make it harder to store data via ORMs, as thouse would need to cross reference stores. This is all highly speculative, and could be countered by: "Well, SQL isn't safe either". But nevertheless it needs consideration.

Solutions without ORMs

The most common argument against the performance impact of ORMs is to use caching. Caching in Hibernate does reduce the number of queries indeed. But caching done in XML, JSON or HTML is often more efficient than object caching. And should you need object caching, other solutions beside ORMs exist which explicit caching of objects like ehCache or Terracott in Java.

What about less boiler plate code due to ORMs? Good DAOs with standard CRUD implementations help there. Just use Spring JDBC for databases. Or use Scala with closures instead of templates. A generic base dao will provide create, read, update and delete operations. With much less magic than the ORM does. And although others think that DAOs are dead, the fraction of persistence increases the need for DAO abstraction. The downside of managing relations yourself isn't as large as ten years ago, with many web databases denormalized. Or with part of the data already in NoSQL document databases.

Think about ORMs the next time you start a project.