Navigate / search

The best job I’ve ever had

I found this old stream of consciousness recently. It had a special resonance as I prepared my talk for DDD North. I worked for a couple of Summers at the amazing TIC Summer Camp in Washington DC. It was the best job I ever had. It was also insanely hard, in the best possible way.

Memories of TIC
Still the best job I’ve ever had and I’ve given up hoping there’ll ever be a better one. My first year at TIC was my first time in the US. Karen picked me up at the airport. On the drive to her house I mentioned Visual Basic, and there and then in the car, the deal was done. We would be teaching Visual Basic. That’s how things work at TIC.

During my second year I suggested that computing and multi-media should be split with each having it’s own director. It was done. No arguing, no meetings, no debate. If someone suggested something and Karen couldn’t see a really good reason not to, she trusted the people she hired. For the Summer of ’96, there were two directors, and I was one of them.

And the campers, the amazing campers, teaching the Pythagorean theorem to a junior so his wrestlers could hit each other still stands out as a great memory.

The other staff, the lunch time chats, the nights out. Getting on the Metro one night with Martin Stephen’s like we’d done dozens of times before, but managing to go the wrong way, and ending up in the wrong part of town with no more trains to get us home, and managing to get home safe and sound anyway.

Being on what can just about be called a boat, in the middle of the Potomac, in the middle of the thunder storm, and realizing that if we sink, we’re taking most of the senior technical staff including two directors with us, but getting home safe and sound (if a little wet).

Swapping puzzles with Vasha Kristov, being led astray by John Mueller, Eating Fried Chicken after dark in Rock Creek Park with Adam Holt, being asked to leave by the Police. But getting home safe and sound.

Always getting home safe and sound.

If I could take one trip in a flying DeLorean, Washington DC in 1994 would be very tempting.

TIC Still exists, and has gone from strength to strength.

The challenge today is overwhelming complexity

Here’s a really great post by Tom Moertel on squeezing every last ounce of performance out of machines back in the day.

It was a time when unrolling a loop to save the few clock cycles or seeing a unique way to use the registers of a chip could take a game from clunky to classic.

Stories of making machines do the impossible are the stuff of legend. The closest we mere mortals came was rejigging our config.sys and autoexec.bat files to free up a little memory. If you’re under 30 even that may sound alien.

Tom’s post is a great read, but there is a real gem of wisdom towards the end, under the heading “To the old days!”.

“The challenge wasn’t overwhelming complexity, as it is today. The challenge was cramming your ideas into machines so slow, so limited that most ideas didn’t fit.”

Turn that quote around. The challenge today isn’t cramming your ideas into machines so slow so limited that most ideas don’t fit. The challenge today is overwhelming complexity.

The challenge today isn’t cramming your ideas into machines so slow so limited that most ideas don’t fit. The challenge today is overwhelming complexity.

I would guess that at this point less than 5% of developers ever need to sacrifice maintainability for performance. I’m probably being generous at that. If you are taking on complexity in order to speed up the execution of a method, or reduce it’s memory footprint, you’re more likely doing harm for no good reason.

But, this post isn’t about code. It’s all too easy to focus on “Clean Code”, have code reviews, refactor relentlessly etc. But, if you deploy that code into an overly complex environment, or using an unnecessarily complex infrastructure, or manage the whole thing using unnecessarily complex ceremony then your code cleaning efforts may be wasted.

It’s interesting how many books are available on how to write “good code”, or how to refactor “bad code”, but there are relatively few if any books about refactoring “bad environments”.

Refactoring should extend to the entire development process. If you can refactor away an unneeded Class, but can’t get rid of an unneeded tool, you’re on the road to ruin. No amount of intention revealing Interfaces or SOLID code will save you.

The phrase “Technical Debt” has been coined to mean the deliberate taking on of subpar “code”, with a view to fixing that problem later. I don’t believe it’s a satisfactory definition.

All too often “Technical Debt” means “We have this one line fix, we’ll come back later and implement it correctly in all of the Controllers, Views and Models that should be affected. I wonder about the logic of treating a change in multiple places as preferable to making a change in one place.

I also wonder whether that one liner change is where time will be lost in maintenance. Even if there is a more “correct” way of fixing an issue, is the code really where your team is losing productive hours?

Or, is it the time needed to set up a development environment? Or figure out how to find a test environment that’s “close enough” to production to be useful. Perhaps you have so many tools that nobody really understands how everything fits together any more.

If there is a “Knack” to getting your code base to build, then clean code is the least of your problems.

When the complexity of the solution exceeds the complexity of the problem, THAT’s technical debt. By “solution” I mean the WHOLE package. Code, Tools, Frameworks, Process, Infrastructure, Documentation, Planning, Review.

Very few of us need to find “clever” solutions any more. The capabilities of machines far exceed almost anything we could possibly want to do. The challenge now is complexity and we should be devoting a lot more of our attention to it.

My 5 Biggest Mistakes

You can’t work in this business for very long before the hope, idealism and intellectual curiosity is beaten out of you and replaced with TPS Sheets, and 15 different tools for telling your colleagues how to configure IIS so that your app will actually run on their machine.

If you’re new to this business there may still be time to save yourself. Go drive a truck, or learn a bit about your city and become a tour guide. On the off chance that you are determined to stay in software development here are my top 5 mistakes, maybe you can avoid some of them.

5. Thinking that things I am unfamiliar with are Bad
Us software developers generally have a well cultivated sense of your own ability to reason about things without actually trying them. We are professional generalisers after all.

“I don’t need to install Linux to know it’s shit”

“LINQ is unreadable”

“No, I don’t use ‘var’ I need to know my types”

At one point I had very strong arguments against var. A colleague tried to make me see the light but couldn’t. Then one day, Eureka, I got it. It was never about ‘var’. In my head the debate was “Save a few keystrokes, at the cost of not having the types in your face”. I thought I needed the types and saving keystrokes wasn’t a priority.

What I didn’t get was that getting rid of the in your face types wasn’t the price, it was the point. The saved keystrokes were incidental. It was never about keystrokes, it was about abstraction. In the same way LINQ wasn’t about writing LESS code, it was about writing code at a higher level of abstraction.

This is different from the static vs dynamic types debate which is a whole other issue, but I know now that I don’t know enough to have a very strong opinion on dynamic types.

Before you reject something as useless or bad, make sure you get the point. Your preconceptions about why a technology exists might be a million miles from the reality.

4. Thinking that things I am familiar with are Good
This is the flip side of the point above but in many ways it’s more damaging. We have a tendency to think the things we are familiar with are the solution to every problem. You can waste a lot of effort and creativity trying to figure out how to press flowers with a hammer because a hammer is what you know.

3. Thinking there’s a right way
When I started building software I was convinced there was a right way to do it. If I could figure it out I could carve out a nice career following my process.

There is no right way. Give up on finding the best way to build software, or even dividing processes, tools, techniques into Good/Bad. It’s wasted effort. One persons good technique will sink another person’s project. One person’s horrible hack will save another person’s project.

2. Thinking that I could learn software development from books
I spent wasted so much money on books. I recently threw a lot of them away. In my defense when I was learning this business the internet was in it’s infancy and there wasn’t a huge amount of curated material out there. Books were how it was done.

Even still, I bought far too many.

I did read a lot of them and I learned a lot from them but I didn’t learn how to develop software. I learned some ideas that could be applied. I could have saved a lot of money by not buying and a lot of time by not reading quite so many books. I could have spent that time actually building more software and more varied software.

Blogs, Screencasts, Online Training are the new Books. I think there’s a danger of replicating similar mistakes, spending too long thinking about software development as a theoretical pursuit, and leaving too little time to build stuff.

You’re making this mistake right now. You think that maybe there’s some insight here that will make you a better software developer. There probably isn’t. Go write some code.

Hey, at least you didn’t spend 40 $/£/€ to be here.

1. Thinking it all someone else’s fault.
If you work as a software developer you will work on a lot of teams and unless you are really lucky, most of them will be terrible. At least they will be terrible from your perspective.

Most software development is terrible. It’s frustrating, it’s unreliable. It’s difficult. It’s tedious.

It’s easy to assume that this is all someone else’s fault. There are solutions if people would just adopt them.

There really aren’t. Everyone including you is trying to figure out how to build software and make things less frustrating. The problem is that one person’s solution is the very thing that frustrates the hell out of you. And it works both ways. Do you have any idea how frustrating it must be for a project manager to have a coder tell them that estimates are useless.

I’m fully conscious of how frustrating it must be to work with me.

I don’t have any magic answer on this point other than to realize that none of us really have THE ANSWERS. It’s probably better to have a team full of people who know that then a team full of people with their own ideas, all of whom think they are right.

Of course there’s no point recognizing this fact if no one else on the team does, so you may have to take yourself out of that situation, and look elsewhere, but at least you’ll know what you’re looking for.

The “Happy Path Model” of software development

Every movement needs an enemy, it galvanises followers, gives a community a sense of some shared identity. Even if Group A aspire to nothing more than to not be like Group B that is at least something to rally around.

“The Waterfall” is increasingly becoming an Alamo for those who aren’t or don’t want to be convinced by talk of “Agile”.

For the Agile community the designated enemy seems to be “The Waterfall Model” and the command and control project management techniques that usually go hand in hand with it.

The anti-waterfall rhetoric from the agile community has been so strong and so consistent that it has created a backlash. “The Waterfall” is increasingly becoming an Alamo for those who aren’t or don’t want to be convinced by talk of “Agile”.

While the Agilistas and Waterfallers slug it out, there is a third way quietly going about it’s business. “The Happy Path Model” is the most popular software development model in history and still by some margin the most widely used.

“The Happy Path Model” is the most popular software development model in history and still by some margin the most widely used.

Adherents of the happy path are eternal optimists. This time it will be different. Requirements are solid, or at worst there will be minor issues that need clarification. Input data will always be clean, complete and easy to work with. No other priorities will get in the way, and even if they do, that’s why we build in contingency time.

Happy path thinking infects every aspect of a project. Project managers will often start with an end date in mind, simply because someone asked for delivery by that date, and regardless of the scope of the project, that date typically remains, chiselled into a gantt chart, because … happy path.

Developers will be asked for estimates and they will underestimate, because … happy path.

Managers will interpret estimates as commitments, because … happy path.

Even as developers realise they are unlikely to hit milestones, they will remain quiet, convinced they can close the gap, because … happy path.

Managers and developers will both allow the scope of the project to increase, or may actually drive the increase, because … happy path.

Happy path thinking infects every aspect of a project.

It goes deeper, to the very core of the product. Happy path thinking results in inadequate exception handling, logging, and even testing. It can result in entire usage scenarios being missed. The result is often brittle, code that is unfit for purpose and difficult if not impossible to maintain and enhance.

Deployment may be a manual process, but why bother automating it? On the happy path it will never go wrong.

Testing may be manual, but why bother automating any of it? On the happy path limited regression testing is all you need, nothing major will ever break.

To even consider Continuous Integration, Automated Build and Deployment, Automated testing, Environment Provisioning, etc is to allow ones mind to turn to the dark side, where manual mistakes are made and things go wrong and people have to work late. A place where features that used to work can break because some unrelated piece of code changed.

These people are not to be trusted, they are typically less productive than developers who get their head down and code the happy path. This academic “agile” bullshit is all fine for hippies in California, but here in the real world we have software to deliver, and the happy path is the path we follow.

Agility is simply the ability to stray from the happy path with confidence.

When stakeholders realise (as they inevitably do) that the happy path isn’t delivering what they actually need, they begin asking for changes. Any change, even a minor change strikes at the very heart of the happy path philosophy. Such requests can create enormous friction between the stakeholders and the development team.

I once worked on a project where a user came asking for a tiny utility that would dramatically reduce some manual work. It was a single form lookup utility, it was read only. It took less than an hour to build and validate. We were not allowed to release it because it was not part of the original specification of the system. Significantly more time was spent arguing to keep this tool out of production that would have been needed to build, validate and deploy it.

Agile teams embrace these practices not because they are how you DO agile, but because they provide the time and space to BE agile.

The reality is that “Agile” is not “Anti-Waterfall”, “Agile” is “Anti-Happy Path”. Agile is about recognising that at the start of a project we are at our moment of maximum ignorance. It’s about embracing the fact that the act of developing software shines a light into the domain and uncovers hidden corners and edges. It’s about realising that trips off the happy path aren’t exceptions, the happy path is the exception.

Agile promotes practices like Continuous Integration, Automated Build and Deployment, Automated Testing, the ability to spin up and destroy environments quickly and reliably. Many believe that these practices are the point of agile. “Doing” these things means you are “Doing” agile. This is a completely backward view of agile.

Agile teams embrace these practices not because they are how you DO agile, but because they provide the time and space to BE agile. Agility is simply the ability to stray from the happy path with confidence.

When can you start?

Donald sat in the large bay window observing the potential candidates as they approached the house. His mind was made up about each of them before they rang the bell.

“I’m here about the gardener job”

“Sorry, the position is filled.”

“Already? OK, thanks, bye”

Again and again all the same. No good. Then…aha! this one.

“I’m here about the gardener job”

“When can you start?”

“You don’t want to ask me any questions?”

“All right, What’s that you’ve got there?”

“Oh this?, I think it’s your rake, it was lying in the middle of the driveway”

“I know, I put it there, when can you start?”