Conventional lies

Every so often I run into supposed rules about development and developers. I call them conventional lies. I’ll look at three of them here.

A programmer over thirty is an unsuccessful programmer

I don’t know who came up with this, but I keep hearing that something must be wrong with anyone still working as a developer after thirty. Supposedly they haven’t succeeded because they couldn’t move up to a higher position. A colleague likes to say, “I made a promise to myself that I wouldn’t be a programmer at thirty.” I think you should have a job you find fulfilling, whatever your age.

I’d even say most programmers age like good wine. Older doesn’t always mean better, but experience counts for a lot. One complaint about older programmers is that they aren’t innovative enough. That’s nonsense too. It’s the developer’s character that matters here. I’ll end the discussion about age and success with a sporting parallel. Hockey goaltender Dominik Hašek is forty-two, still among the very best in the NHL, and nobody dares question his ability.

An architect shouldn’t code

To code or not to code? Supposedly an architect should keep some distance, leave coding alone and look after the application architecture. In my view, any architect who stops coding completely loses a feel for how technologies are actually used. That harms most of their estimates and decisions. A purely theoretical architect is a disaster for any project.

If I’m to be responsible for a system or part of it as an architect, I need to understand its architecture and be able to defend the practical solution I’m responsible for. Some people think architects should stay in touch with reality by reviewing code. I think static analysis tools are a better fit for code review.

An architect should help design an API, for example, and also help implement it and make sure the implementation stays true to the design. An architect who designs something and considers their work done, or can’t make the case for what they designed, is a bad architect.

Don’t anticipate the future. It’ll turn out completely different.

I heard this about API design. We recently discussed an object for which we created an interface mirroring its public methods. I like using this pattern for APIs consumed by a client in a different layer of the application. Whenever we design an API, I’d argue we’re anticipating the future. So it’s worth keeping the door open by avoiding a requirement that clients use a concrete class.

In that sense it’s pointless to anticipate the future for something used only once or very easy to refactor. But how often do one-off solutions end up being reused? I’d say nearly all of them evolve that way. Refactoring them can then be a disaster in larger projects. The future may be different, but usually it isn’t so different that we can’t anticipate some of it and save ourselves a lot of work later.