“I would have written a shorter letter, but I did not have the time.”

Blaise Pascal was a smart dude. Much of what he had to say is surprisingly applicable to software development (which is why if you show me a well-read developer I’ll show you a good developer). The above quote came to mind yesterday during an all-hands meeting where we were discussing our company core values:

“We build elegantly simple software.”

I love that sentiment. But make no mistake: elegance and simplicity take more time to build than complexity. This is true up and down the process, from prototyping, to requirements development (holy cow is this step often rushed; we’d do well to heed Mark Twain here), to implementation and testing.

My first task after moving to San Diego was to help a development team push through a particularly challenging set of features for a digital mapping system. Twelve hour days and weekend work was expected, and all tasks had to be done as quickly as possible. The technical architect had put together a mockup of a few of the screens using a prototyping tool, and unfortunately the quickest way to make those screens a reality was to copy and paste the auto-generated XAML (sort like Android’s XML-based UI markup, but for C#) and then tweak it. This led to a ton of duplication, with hard-coded screen positions everywhere. By the time we got the initial release of the application to the test team, it had become an unmanageable nightmare. But we limped along, duct taping bugs as they came up.

Then came the back-breaker, under the guise of a single requirement: “by the way, this needs to work in landscape as well as portrait orientation”. Just like that, our brittle implementation became untenable. It needed a complete re-write.

I was assigned the task, and (thankfully) given a month to do it. My delete key was never busier as I learned how to abstract and consolidate the XAML, replacing tons of repeated values and cleaning up duplication. Turns out XAML is pretty easy to author and has plenty of features for writing clean and responsive implementations, but no one had bothered to learn it. By the end of my process, in addition to adding a landscape capability, I’d shrunk the code base by over 90%, and gained a near 5x boost in performance to boot.

The moral of the story? Well, actually there’s two. The first is that using SLOC is a dumb measure of productivity (I was averaging about -10,000 lines written per day or something like that). And the second is that the best developers delete as much code as they write. Maybe even more. Refactoring isn’t a separate step on the task list; it’s part of every task. Yes it takes more time. Yes you might need to let go of your ego and trash that super clever function when it becomes unneeded. But your product will be better for it.