Running a single Clojure test using leiningen

I’ve recently been working in Clojure on some code that really benefits from parallelization but doesn’t need to squeeze the last available cycle out of the machine.

Of course, if you’re using Clojure, you’re also using Leiningen as the universal build and configuration system. Accept no substitute. Now if I could only remember the syntax to run a single test when I’m refactoring some code and need to reflect the changes in the test suite via the build system and not just from inside the REPL?

Ah, here it is:

lein test :only TestNS/function

This is of course self-explanatory if one’s brain is running in clojure mode and not only the editor.

Go read Matt Kline’s post on Shipping Culture, now

Over on bitbashing.io, Matt Kline has an interesting blog post on how Shipping Culture is hurting us as an industry. Hop over there and read it now, because he addresses another case of the pendulum having swung too far. Your developers take a long time to get a new version out? I know, let’s make them ship something half baked. Quality is overrated anyway. Especially when you don’t have a reputation to lose as a maker of quality software.

If you only read one section of the post, read the part about Anti-Intellectual bandwagons. It summarizes one of my big annoyances with this industry, namely that we seem to dabble in collective amnesia combined with a side helping of AD… oh look, shiny!

That said, we are good at reinventing the octagonal wheel with a slight wobble around the axle.

 

 

Why I’m strongly opposed to modifying third-party library code

I encounter this on a fairly regular basis – a project uses a third-party library and there is either a bug in the library that we can’t seem to avoid hitting, or there’s a feature missing or not 100% ideal for our use case.

Especially when dealing with an open source library, at this point someone will inevitably suggest that we have the source, so we should just fix/hack/modify the library and get on with our lives. I’m massively opposed to that approach, with essentially one exception I’ll mention towards the end.

So, why am I so opposed to changing a third-party library, even if I have the code and the rights to do so?

It’s very simple – it adds to the maintenance headache. If I suddenly find myself having to change outside code, I have to be able to maintain it going forward. That means I:

  • Suddenly have to have a place to keep it in source control so I can maintain my patches going forward
  • Updating the library becomes an exercise in merging the local changes with the remote changes and should the author of the library make substantial structural changes, it’s not even clear if you can easily integrate the new version into your patched version. You might well end up in a situation where you locked yourself out of taking future updates because the effort involved in porting your changes forward is so big that you can’t reasonably accommodate it. You find yourself in a dark room, owning another piece of code that by rights, you really shouldn’t and it’s going to unnecessarily increase your maintenance effort because all of a sudden, you’re not only responsible for bugs in your own code, but also bugs in the third-party library code that isn’t so third-party library anymore.

There is one exception I’d make to the rule of not touching third-party code and that is, if you talked to the maintainer/owner of the library, agreed that what you’re trying to do is actually beneficial to everybody involved and most importantly, that the owner of the library is willing to take your change and integrate it into their next release. Most open source projects will be more than happy to accept contributions this way as long as they fit in with their vision of how the code should work. Same goes for commercial libraries, too. Just talk to them beforehand to make sure it’s not a misunderstanding of the code at your end.

Under those particular circumstances, yes, I’d accept that it’s OK to change third-party code. Any other reason, don’t do it.

Butbutbutbut, I absolutely have to change an important third-party library because their API doesn’t fit into our model anymore?

No you don’t, sorry. Either replace the library or write a shim that takes care of your needs, because I don’t need to have a discussion with you in a few years time as to why we aren’t able to upgrade a library that we decided we needed to hack and now are tied to an old code base that’s potentially buggy and full of security holes.

The coder/programmer/software engineer debate seems to be rising from the undead again

First, a confession – I actually occasionally call myself a coder, but in a tongue in cheek, post-modern and ironic way. Heck, it does make for a good blog title and license plate.

Nevertheless, with all the recent “coding schools” cropping up all over the place – at least if you are in the Bay Area – it does seem that being able to code in the context of a reasonably sought after web technology without much further formal training is the path to new, fulfilling careers and of course untold riches in an economy where recent graduates in all fields have problems finding work. Well, at least a career that allows you to rent a room instead of crashing on somebody’s couch.

There are some problems with the whole “mere coder” thing. Dave Winer has some interesting thoughts on his blog, and I agree with a lot of what he says. Scott Radcliff has some additional thoughts, which I also find myself agreeing with a lot.

The process of building a software system is a lot more than just coding unless you subscribe to the view that all the coders do is to take the gospel handed down by A Visionary Leader and convert it into software. Anybody who’s ever built a moderately complex system knows that software doesn’t happen that way, at least not the type of software that doesn’t collapse under its own weight shortly after its release. Of course that doesn’t sit well with the notion of The Visionary Genius that is all that is required to build the next and the narrative doesn’t work at all once you recognise that building software is, in most cases, a team sport.

Expecting someone who has learned to write code to o create a great piece of software is like expecting someone who’s just gone through a foreign language course of similar length to go and write the next great novel in that particular language. Sometimes you get lucky, but most of the time the flow isn’t there, the language isn’t yet used in an idiomatic way and all that together makes for less than an enjoyable experience. Some of the people who manage to enter the profession of software development will learn on the job and grow into people who can build robust, maintainable systems and those are to be congratulated.

The way most people use the term coder, ie in a non-postmodern ironic way, reminds me very much of the time when a programmer’s job was to unthinkingly program as part of a little cog in the giant waterfall development machine, which led to the WIMP (Why Isn’t Mary Programming) acronym. Basically, if the keyboard wasn’t constantly clattering, there was no programming going on.

That said, maybe we are at a point in time where an army of coders as the modern equivalent of the typing pool is able to create good enough software. Given that most users are conditioned to believe that software is infuriating and buggy, we as an industry might well get away with. Is that the world we want to live in, though?

As creators of software, we do have the ability to choose the environment that we work and live in. If you care about quality, work with like-minded people.

Me? I prefer to call myself a software craftsman. I’m not an engineer, I write code but that’s almost an afterthought once the design is figured out but at the end of the day what I do is build something that wasn’t there before, using vague guidelines that are wrong as often as they are right while trying to tease out what the customer needs rather than what they tell me they want. In most cases there is no detailed blueprint, no perfect specification that only needs to be translated 1:1 into lines of code. Instead, I get to use my experience and judgement to fill in the blanks that most people – myself included – probably didn’t even think were there.

Sounds like a job for a craftsman to me.

Initial thoughts on Swift

Like pretty much every other programmer with a Mac, I’m currently looking at Swift. Will I write anything but toy programs in it? I don’t know yet – I don’t really write any Mac-ish software on my Mac,  just unix-ish programs. If Swift doesn’t escape the OS X and iOS ecosystems it’ll be a nice exercise in a neat language that’s not really that relevant to the world at large, or at least to my part of the world at large. Not that this sort of vendor lock-in can’t work well – Visual Basic 6, anybody?

I hope Apple will open the language to be used outside its software ecosystem but from what I have read so far, it’s tightly integrated into the iOS and Mac OS X runtimes so I’m not sure how feasible that even would be. Still, I’m pretty sure it’ll remain on my list of languages to play with.

Make GNU Emacs play nicely with a German keyboard layout on Mac OS X

I used to use Carbon Emacs on OS X for quite a while, but with the release of Emacs 24 I switched to the stock GNU Emacs distribution. While GNU Emacs works fine on OS X, once you throw a German keyboard layout in the mix it doesn’t work so well as OS X uses Option + Number keys for a variety of characters needed for programming like [] and {}. GNU Emacs uses Option as Meta out of the box so the key mapping doesn’t work overly well, especially if you do a lot of programming in the C family of languages.

I finally got fed up with this restriction as it seriously affected my enjoyment of cranking out code under OS X. A bit of duckduckgo’ing gave me the necessary settings to use Command as Meta and pass Option through to the underlying OS. From my slightly hazy memory, this was the default layout for Carbon Emacs.

Here’s the code that will switch the keys around:

(setq mac-command-modifier 'meta
      mac-option-modifier 'none
      default-input-method "MacOSX")

Yes, there is also the whole argument about the unsuitability of using a German keyboard layout for programming. A lot of German programmers I know switched to UK or US layout keyboards to make programming easier.

I can drive one of those keyboards if need be but I’m both a touch typist and I rely on Kinesis Advantage keyboards for my day-to-day work thanks to an injury from a less than ergonomic desk quite a few years back. While this old dog is generally happy to learn a new trick or three, I draw the line at switching keyboard layouts when there are other options available.

If we consider software creation a craft, Is it time to”bring our own tools”?

If you look at really productive programmers – like the top 10-20% – there are usually a couple of characteristics that they share. Aptitude and in-depth understanding of both the system they are working on and the technologies involved is obviously one very important factor. Another factor that tends to be overlooked is that these programmers are also masters of their tools in the same way that a master craftsman – say, a carpenter – is also a master of their tools. That includes potentially obscure tools, and the ones handed down from grandps or found at a yard sale.

I think that mastery of your tools plays an important role in your ability to be a productive software engineer. If your tool interrupts your workflow because you need to figure out how to accomplish a task at hand, you immediately waste precious brain cycles on this disruption rather than being able to use them in the flow of software creation. That sort of disruption can easily drops you out of “the zone”, and those brilliant thoughts might never make it into your software as a result.

There’s also a trend that I’ve seen over quite a few years in a lot of companies (usually large, with IT departments that most developers would find overbearing, but it’s not limited to these companies) limiting the tools that are available to developers. The usual attitude seems to be that if a certain tool is not included in <insert development environment of choice>, it is not needed for serious software development and thus developers are only requesting these tools because of their magpie like tendencies or worse, because it allows them to polish their resumes and then wander off and get a better job.

Leaving aside the latter “justification” – if you work for a company like that, my suggestion is that you find yourself some career opportunities elsewhere anyway – you’ll end up running into the issue that the one tool you need hasn’t been requested by anybody else and thus is not on the very short “approved” list. Your manager will have a hard time justifying the expense because nobody else “needs” that tool and thus requested it. Plus, IT departments tend to have an ingrained dislike of exceptions of any kind, because it usually tends to make their job a lot harder. A short list of approved software with everything else banned does make it possible for them to support thousands of machines, but at the expense of inhibiting the creation of a work environment that is designed to give people all the right tools they need for maximum productivity.

Most craftsman own their own tools. A carpenter will show up at a job site with their own tools, a car mechanic uses tools he’s acquired over his career. If you subscribe to the view point that software development is a craft and not an assembly line operation, then maybe it is time for us software engineers to step up and tell our employers or clients that we don’t expect them to pay for certain tools, but we will bring them with us and expect to be able to use them. Of course, the latter is going to be the issue – there will be clients and workplaces with the IT policies designed by Mordac The Preventer’s cousin that will under no circumstances allow a tool on the premises that has not gone through an 18 month vetting process by the secret IT ninjas – but to me this is the sign of an environment that is conducive to good software development if it is being recognised that a craftsman’s tools play an important role in both their ability to produce quality work and enjoy producing said quality work.

If your development team doesn’t enjoy what they’re doing, they’re not going to be at their best and create the absolute best software they can. And we already have virtual shelves of “good enough” software available, we don’t need more of that.

While there is a need for some standardized tools like the compilers and the basic build environment – I really do not want to work in an environment where everybody gets to bring their own compiler, I’ve seen how that movie plays out, thankyouverymuch – there is absolutely no reason to hire someone who is a SublimeText/VIM/MultiEdit/BBEdit wizard and force him or her to use Notepad or edlin. Let them bring their own editor, IDE plugins, customizations and let them use it. Let them use the shell they can drive in their sleep.

The same goes for certain types of specialised tools or plugins, heck, even keyboards. For example I expect to use a certain type of keyboard at my workplace due to an old injury and I’m happy to bring one in so I don’t have to use the “but it came standard with the Dulls we buy and it is the only keyboard you are allowed to use” $5 RSI-waiting-to-happen piece that gets inflicted on seemingly everybody.

That said, I am in no way advocating anarchy in the workplace here. There are certain limits that need to be set in a case like this – for example, one of my rules is that no matter what editor you use to write your code, it has to apply the same formatting in all editors across the team. Yes, as a result everybody in the team will have to tweak their editors to ensure they don’t litter the code with tabs instead of spaces and result in formatting that make the source code unreadable in six out of ten editors used by other members of the team. The code will however look the same in everybody’s editor and its readability (or lack thereof) will be the same. Large bodies of code are already hard enough to read as is, we don’t need to introduce additional hurdles.

You also don’t get to pick your own build tool and thus be the only person on the team using CMake while everybody else is using MSBuild. Or use the latest nightly build of GCC when the production code is built using Visual C++.

At the end of the day it’s a balancing act, but as a manager you want to ensure that the tools your developers use are the ones that provide the least distraction to them. You absolutely do not want to inflict tools on a team that get in the way (ClearCase, anybody) when there are tools out there that are designed to complement the workflow rather than inhibit it.