DEV Community: Alex Fawkes

The Joel Test: 20 Years Later

Alex Fawkes — Wed, 19 Dec 2018 23:44:39 +0000

I'm getting a head start on celebrating the two-decade anniversary of The Joel Test. If you haven't heard of Joel Spolsky, or otherwise live under a rock, he's the CEO of Stack Overflow and co-founder of Trello and Fog Creek Software (now Glitch). He's a hardened software veteran, with a background going back to the Microsoft Excel project in the early 90s.

He also hosts a very popular blog at Joel on Software, though his activity there has dwindled over the years. That's how I originally found him, early on when I first started programming, and I've been a huge fan ever since. It helps that he's a fantastic writer, articulate and insightful while still being fun and accessible. More importantly, I've always appreciated his values, in his attitude of respect for the craft of software development, the stakeholders of the companies he runs, and the members of the communities he builds.

So what's The Joel Test? If you didn't just read through that link, it's a 12-item, dead-simple checklist for evaluating the effectiveness of a software team. Hitting all 12 won't automatically make your team great, but hitting 10 or less is almost certainly going to cause problems. It's obviously not iron-clad, but it's a useful heuristic, and I've definitely used it during interviews - it's a great conversation starter if nothing else. So, two decades (in two years) later, what's changed? Let's walk through it:

1. Do you use source control?

This is just as relevant today, and much easier to attain. Git is the clear Goliath today. You can use other source control systems, but there's really no compelling reason to. Platforms like GitHub and Bitbucket make it practically effortless to maintain a production-grade source control system, so there's no good excuse for not taking advantage of the technology.

2. Can you make a build in one step?

Still true, and the field has moved forward here. With modern CI/CD systems like Travis, you can hook into your source control system to automatically build (and release!) in zero steps. This is more relevant in some fields (web) than others (embedded), but you should still definitely automate your build process - bonus points if it runs entirely without manual interaction.

3. Do you make daily builds?

Daily is good, but today it's easy to do even better. Again, with modern CI/CD systems, you can build on every commit before merging changes to your master branch. Broken builds mean downtime for unhappy developers, and have you ever spent time with unhappy developers on downtime? I have. You shouldn't. There's very little reason for the build to ever be broken.

4. Do you have a bug database?

JIRA is pretty standard here, but maybe heavyweight for a lot of teams. I really appreciate his point about creating a dead-stupid five column table - if a Google Sheets documents works for the scale of your team, then keep it simple! You'll know when you've outgrown it, and then there are plenty of more powerful bug tracking tools available for upgrade. The important point is to write down your bugs in one place, and make everyone go there.

5. Do you fix bugs before writing new code?

In general, this is good practice. I'd argue there are business models where time-to-market is critical, and letting small, especially cosmetic bugs slide is just plain economic.

But I've personally worked in +5 million legacy C/C++ codebases where this wasn't practiced, and I can assure you - keep it up long enough, and software behavior becomes so unpredictable and erratic in response to even minor changes that new development is practically impossible. Even when you can move forward, estimates are meaningless, schedules are unreliable - it's just a mess. If you want any meaningful level of predictability in your development schedule, you need a reliable foundation to build on.

6. Do you have an up-to-date schedule?

This one is tough. Personally, I don't believe that estimation is practical or reliable in software development, and insistence on deterministic and reliable estimation is counterproductive and misses the point. In software, if it's a solved problem, there's a library for it - use it. If it's not a solved problem, how do you expect to estimate how long it'll take?

Joel has another great post on this (there's always one!) - Evidence Based Scheduling. Basically, he recommends sizing upcoming work in detail relative to work completed in the past, and then projecting dates forward based on historical time-to-completion. But - and this is extremely important - the result is a projection, not a commitment, and takes the form of a range with attached confidence values, not a single date.

7. Do you have a spec?

Programmers still hate this, and it's still just as important. It's not that it's difficult, just that it involves two things developers tend to avoid: writing documentation and talking to people.

Before you start writing code, you should know what user problem you're trying to solve. If you know what user problem you're trying to solve, you should be able to quickly write out a few sentences describing it. Now, just put those sentences in a shareable doc - don't make it more complicated than it needs to be. Now share that with a team member, preferably someone closer to the users than you. What do they think about it? Revise until they're happy with it - now you can code! In practice, this cycle is low-overhead but extremely valuable. Make it a part of your normal workflow.

8. Do programmers have quiet working conditions?

Probably not, but they should. The trend towards open offices is a huge push in the wrong direction from a developer productivity standpoint. Joel's stance has always been "programmers get an office, with a door."

It doesn't help that the tech industry is concentrated in cities with (not unrelated) extremely high cost of living and real estate prices. Open floor plans are tempting to management for a reason. But if you look at the research, and do the math, the cost of interruptions to highly-skilled, well-compensated, intensive knowledge workers exceeds the cost to put up some walls and doors.

(As a practical aside: noise-isolating headphones help if you're a developer without a private office and aren't going to win that battle. I recommend the passive route - the classic Sennheiser HD 280 Pros are fantastic.)

9. Do you use the best tools money can buy?

Being successful in software development requires a certain inclination and level of ability that's just fundamentally rare. It's a meme in the industry that there's a "developer shortage." Whether you buy that or not, it's a fact that a huge number of software development jobs stay unfilled, often until companies give up and close the position. There just aren't enough people entering the industry to fulfill demand.

High demand, low supply means high market rates - the average salary for a senior software engineer in 2018 is upwards of $110k. You can reasonably double that to figure the cost-to-employer, including the overhead of benefits, administration, rent, utilities, equipment, etc. That means if you have a software engineer on staff, you're spending roughly $100 every hour just for them to show up!

If you can invest in some tooling that saves a single engineer even 10 minutes a day, that's $3000 a year, every year. It really doesn't take much to justify the expense.

10. Do you have testers?

The rise of automated testing has ironically reduced emphasis on this (which was never strong to begin with), but it's still a false economy. Ultimately, an actual human, who didn't write the software, and probably doesn't think like a software developer, is going to sit down and try to use it. They're going to immediately do something that the developer didn't anticipate, and the system will break in ways the implementer didn't foresee. That user isn't going to file a bug report - they're going to quietly close your app and Google for something else. If someone ever mentions your software, that's the story they're going to tell.

So either you don't test, and you lose users, or developers end up doing the testing, which is like having surgeons clean the bedpans. That way there's no need to hire additional nursing staff!

11. Do new candidates write code during their interview?

This is definitely still important, but the emphasis has shifted through automation by tools like Codility. Interview time spent on assessing technical skills is taken away from time assessing values and culture fit, which are likely better long-term indicators of candidate success. Pseudo-code and general problem solving are great to help assess how a candidate frames, deconstructs, and solves problems, but nuts-and-bolts coding without available reference material doesn't simulate any reasonable working condition in actual practice.

Definitely have candidates write and test actual code during the hiring process, but it might not be the most effective use of direct interview time given the tools available today.

12. Do you do hallway usability testing?

This was always a bit of a goofy one just due to the idiosyncratic wording. Whether or not you find it endearing, his core point that you need to watch people actually try to use your software will always be valid. The subpoint, that it doesn't have to be a heavy formal process, is also extremely relevant. Grab the person sitting next to you, sit them down in front of your welcome screen, and ask them to complete some specific task.

If you aren't already doing this regularly, or something similar (e.g. systems to automate this with screen capture), you'll likely be surprised at how quickly issues surface, and how consistent those issues are across testers.

Addendum: 13. Do you do automated testing?

I saw Joel speak at a corporate event a few years back, and someone asked him what he would change about the The Joel Test given recent developments in the field. The point that sticks out in memory is that he'd likely add something about automated testing - not necessarily TDD, or any heavy formal process (notice the theme?) - just that you're thinking about and implementing strategies to automate your testing efforts where feasible. I'm totally on board with this, so I'm throwing it in as an informal #13.

Where does this leave us?

Overall, Joel's original 12 items have stood up well over the past two decades, which is actually an extremely long time in software development. Still, there have definitely been relevant changes that necessitate some tweaks. When I use the The Joel Test in the future, I'm going to use my own revised version:

Do you use Git, or some lesser source control system?
Can you build and release in one step?
Do you build and test before merging to master?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you write a spec before writing code?
Do programmers have quiet working conditions free of interruptions?
Do you use the best development tools money can buy?
Do you have human testers?
Do you do automated testing?
Do new candidates write code as part of the hiring process?
Do you watch people actually try to use your software?

This post was originally published to CheckGit I/O.

Software Development: Some Things Never Change

Alex Fawkes — Thu, 13 Dec 2018 00:11:57 +0000

As a field, software development moves fast. New technologies come and go, methodologies become popular and then decline, style and aesthetic preferences change, and user expectations rise as fast as technologists can deliver.

This backdrop can be misleading. Sometimes, things don't change. It's important to take the occasional opportunity to reflect on how we got where we are today. Here's a few general software development practices that, at a fundamental level, have remained constant through the years:

Code Reuse

Even back through the 1960s, developers at early tech companies like Xerox were pushing for the increased abstraction and modularization that have allowed us to develop the large-scale software systems we have today. This push eventually gave rise to the higher-order machine languages like C, then bytecode languages like Java, and on to dynamically-interpreted languages like Python. These languages allow developers to produce more functionality with less fuss around implementation details like memory management and data structure.

The major programming paradigms come into play here as well. Structured programming, object-oriented programming, and functional programming all have roots going back to the 1960s. Structured programming promotes reuse of logic through control flow ('if' statements and 'while' loops). Object-orientation modularizes and encapsulates data and algorithms beneath easy-to-understand, interchangeable interfaces. Functional programming promotes reuse through deterministic behavior and minimization of side effects - it's safe to reuse code if you know you can just throw out any part of the result you don't need.

The current trend seems toward polyglot environments - breaking apart software systems into modules written in separate languages and paradigms depending on suitability to domain, but interoperable through standard protocols. The rise of open source is also a good example of code reuse, where basic foundational technologies can be constructed and shared by the larger community, allowing projects to focus more fully on their differentiating value.

Design & Architecture

The author of The Mythical Man-Month, Fred Brooks, has stated that one of the hardest lessons learned through his experience with the OS/360 project was the importance of a consistent architectural vision. Initially lacking one, the team found that the codebase became too difficult to understand and reason about.

Not every project is on the scale of OS/360, but the basic importance still applies. In general, it's better to have a clear and consistent vision of a piece of software before jumping into coding. It doesn't have to be a formal process resulting in a mountain of documentation, but every change should start with an understanding of its general scope and purpose within the larger system.

Personally, I try to keep SOLID principles in mind before starting any implementation. It doesn't need to be dogmatic, because engineering is all about context and tradeoffs, but it's important to have a common language to use in order to understand, analyze, and discuss design decisions. This also goes a long way toward maintaining quality in the long-term, especially for large codebases and distributed teams.

Source Control

Bell Labs was using SCCS to manage their software revision history back in the early 1970s. Proper version control is essential for managing the integration of complex changes - again, especially true for large codebases and distributed teams. It also plays an important role in quality control, allowing developers to pin the first reported occurrence of an issue to a general timeframe in version control, which can then be inspected to help debugging.

Today, Git has become the default version control system. Its distributed model makes it easy to fork existing projects for custom changes, and provides a powerful and convenient mechanism for contributors to request their changes be merged back to the master branch for official distribution. Whatever source control system works for your team, be sure you have a sane way to track how, when, and why your system is changing over time.

Testing & Quality Assurance

Traditionally, QA processes were borrowed from existing engineering disciplines, which had originally developed them with an eye toward physical systems. Large organizations would produce detailed documents outlining specific manual testing procedures, which were carried out by teams of trained, dedicated testers.

Today, there's a definite trend toward minimizing manual QA activities, especially with the rise of developer-driven automated testing. There's still a place for manual QA. For one, it's important that software be tested by someone other than the author. Secondly, it's good to have a non-developer sit down with the software - what's intuitive to a software developer familiar with the project isn't necessarily intuitive to the end user.

Automated testing is generally good practice, but only to the extent that developing and maintaining the tests actually contribute to end user value, and couldn't more effectively be performed manually (if less frequently). Either way, testing is and will continue to be an essential practice in the field.

Talking to Users

For a variety of reasons, software developers have a tendency to forget this one. That's unfortunate, given its special importance. Ultimately, software ends up in the hands of end users, who are generally using it for things that aren't software development. If you're not talking to your users, you don't know what you're trying to build.

Early in software development, users were specialists who worked in-house, making communication relatively easy. With the advent of microcomputers and mass market software in the 1980s, large companies developed teams of customer relations experts to keep programmers informed of end user needs.

Today, with the dominance of Agile processes and their derivatives, it's common for developers to talk directly to end users. Ideally apps have multiple built-in feedback mechanisms, and social platforms are made accessible for communities to form around a given technology. However you do it, you should definitely stay in touch with your users.

And so...

Software is a special animal. Its extreme flexibility, ease of distribution, and near-zero marginal cost makes it possible to build and deploy systems so massively complex that no single human can possibly understand them in full. This has been an identified problem since the very early years of the practice - limitations in software development come down to intelligent management of complexity, and abstracting out components to a scale that individual contributors can understand and reason about.

All of these practices - code reuse, design and architecture, source control, testing and quality assurance, and regularly talking to end users - are essential to the production of good, working software. They've been in place since the infancy of software development, and if I'm allowed to speculate, will continue to be practiced for as long as people are writing software.

This post was originally published to CheckGit I/O.

You Suck At Code Review

Alex Fawkes — Thu, 29 Nov 2018 05:46:00 +0000

That’s OK, though! Code review is hard to do correctly, especially if you never start. We’re experienced code reviewers, and we still struggle with it — working with other people is never easy, and at its core code review is a social process for developers to help each other write better code.

Code review is an opportunity for us to spread valuable knowledge between our fellow developers. Let’s take it seriously.
There are all sorts of ways this can go wrong. Here are a few comments I’ve personally seen that I’d rather not have:

“We don’t have time for code review.”

This is the worst mistake you can make. There’s strong empirical evidence that code review catches more bugs faster than software testing at a fraction of the cost. Even worse, organizations that aren’t doing code review frequently aren’t testing either. It’s not the bugs that go away when you don’t catch them — it’s the users.

“Seriously? Do you even code?”

Don’t be a jerk. As long as your fellow developer is willing to work with you in good faith to reach a mutually agreeable solution, they deserve the benefit of the doubt. People are generally doing their best, in their own way, and insulting their capabilities just drives a wedge through your team that makes it impossible to reach the goal. Show them a better way, and accept that it will take time and repetition before they really get it.

“How dare you!”

Don’t take criticism personally. Not everyone is going to like or agree with your code. If you can’t take constructive criticism gracefully, you’re seriously hampering your ability to refine and hone your craft. You’ll never be great without honestly listening to what people have to say about your work.

“Only bad developers write singletons.”

Life is full of nuance. Not every problem is important, and every decision has trade-offs. Slapping together a singleton to magically share state between two parts of the system isn’t pretty, but rearchitecting the system to gracefully cover the corner case is an exhausting way to waste time and money.

“This is wrong.”

If it’s wrong, it’s wrong — but is that helpful? Code review is an opportunity to share valuable knowledge between developers. Why not help them understand the underlying principles, and then lead them to discover the problem on their own? At the very least, give the correct solution — but don’t expect them to get it right next time.

“This is ugly.”

Ask your users how pretty the code is. If the answer surprises you, you have some reflection to do.

“I don’t like this.”

This isn’t a wine tasting. Does the change meet the requirements of the ticket and all enforced standards of quality, maintainability, and style? If so, the code is better off with the change. Ship it!

“…OK, whatever…”

If you don’t understand the feedback you’re getting on your code, don’t just go along with it. Accept the possibility that you’re wrong, or that there’s a better way to do it, clearly articulate your original thought process, and ask clarifying questions. This is a great opportunity to learn from someone else’s experience.

“Just glance over it real quick.”

Everything is contextual, but on average the empirical evidence suggests review should take between 200 and 400 lines of code per hour for optimal results. Much less and you’re just going to end up fixing the issues in production at 10x the cost.

“I’m still not happy with this indentation.”

I’m still not happy my change isn’t merged! If you’re spending much (any) time discussing style, you’re wasting time — the trick to style is that it doesn’t much matter which style you choose, just that everyone uses the same one consistently. Set up an automated linter with the default settings for your language and save the discussion for actual implementation issues.

That’s it!

Thanks for reading, everyone! I hope this was helpful. Let me know in the comments if you’ve had similar experiences, or if I’ve missed anything you’ve personally struggled with.

Also, if you’re personally interested in topics surrounding code quality and software development, come see what we’re doing with CheckGit!