12 powerfull steps to web development greatness – Joel Test Guide

Digital agencies struggle with one concept – they sail in the marketing ocean with other creative, PR, design, or full-service teams while ignoring one big wave – they are, in reality, a software development business. Yes, all of your web applications, mobile games, digital campaigns and parallaxed micro-sites have one big thing in common… they are software applications and in this ocean, team quality matters. In a way that will make or break your ship.

Joel Spolsky, founder of stack overflow and Trello, wrote 12 simple rules of measuring quality of digital teams. This test is not a comprehensive check and thorough guide, but more of a YES / NO checklist that will give you feedback on how serious your team is. Note that companies like Google are running a score of 12 all the time. You can get along if you have scored 11, but you’re in trouble if your production is running on 10 or lower. To be honest, I wanted to write about the Joel test for quite some time, but haven’t really been confident that our own team would score it well 🙂

Here I will walk you through how the Neuralab team writes code and in the end, builds web & mobile products. Most importantly, I will give you some tips on how your team can also pass the Joel test and write stable quality code. On a time and on a budget. It just requires some discipline and healthy reasoning!

1. Do you use source control?

This is a no-brainer. Yes, we use Git on top of a Bitbucket cloud server so every change in the code is visible to every related team member. Our typical developer day consists of several commits and pushes. We target to have a commit connected to every functional change or bug fix.

Tips for your team: Bitbucket is free for small teams so just start to use GIT. There are tons of tutorials online so there are no more excuses for not using Git. A good starting point is the GIT microsite by Atlassian.

2. Can you make a build in one step?

There are no classical “builds” in web development as we constantly push changes to staging and production servers. We mainly use Deploybot for pushing code to either Rackspace or AWS servers and any developer who has access can push changes to servers instantly.

Tips for your team: Deploybot and AWS cost merely 5$ per month per virtual machine. With these in place, your Git code will fly fast to staging and production servers where you can roll back, backup and test if anything goes wrong. DeployHQ is a good alternative to Deploybot (and Digital Ocean is also a good alternative to AWS)

3. Do you make daily builds?

Typically, there are no daily builds in web development, but you can properly tag and check your commits. The thing is that most web development projects are organized in sprints where you agree (with a client) that you will produce X features in two weeks and publish the code first on staging, and then after testing, into production. You also need to have a unified development environment, tools and libraries so that developers don’t step on each other’s toes.

Tips for your teams: If you’re working on LAMP / WordPress application development use one stable environment like VVV or Scotchbox, and then stick to it. All developers should use only one dev environment, set of tools and libraries so that there are no discrepancies in building projects. Bitbucket also supports continuous integration and selenium testing via BrowserStack, but you can also use a standalone OpenSource Jenkins server and Selenium testing suite. Free.

4. Do you have a bug database?

We use JIRA for tracking all work items, including bugs. Team members usually submit work items through JIRA and clients usually submit bugs through Zendesk ticketing system (which in the end is connected to JIRA for production planning). For official launches of major releases (publishing v.1.0, v.2.0, etc.) we mostly use Google Sheets as they have an instant online connection with all stakeholders so we can communicate about bugs and features in real-time. JIRA is connected to Bitbucket so you can link resolved bug JIRA ticket with the commit on your Git repository.

Tips for your team: if you manage a small team, start with Google Sheets. These are flexible, but powerful tools for communicating various work aspects. In some way, full-blown project management tools will never have the flexibility of Google Sheets (and small teams need to stay flexible). The reason for this is that you can organize a sheet of data any way you like and any way you can. You can also color code it, bold it, strikethrough, make c4lcul4ti0ns and rearrange rows & columns to fit your project needs.

5. Do you fix bugs before writing new code?

We will not implement new features until bugs in the current release are solved. There are some additional rules. For instance, quickly improving current UX/UI functions is allowed so we will improve deployed functionality while the other team members are chasing bugs.

Tips for your team: do not allow stakeholders and clients to throw new functions and wishes at you while still polishing bugs from the current launch. This is connected to point 4 where good bug base documentation is the first thing you should have. The second thing is discipline. A technical debt of software projects is a real problem that will cost you time & money so keep an eye on this topic. Educate yourself and your team.

6. Timelines & Schedule

The up-to-date schedule is the trickiest part of our experience. Project scope changes as businesses and markets change. This is normal and in the end, healthy. While it is good practice to write down changes in the initial functional specification (and update the cost of the project), it is somewhat complex to do that in a stable and quality way. The inherent complexity of software projects is the number one reason for that – One module can seamlessly connect to 3rd party API, but if the client needs a small tweak in function, it can completely destroy the currently implemented function. For example, adding one extra field to the checkout page in eCommerce sites could block the entire buying process and cost the company several thousand dollars. The software IS that complex.

Tips for your team: First, educate the client and stakeholders. Clearly explain why your team needs a schedule of implementation, a good bug base (4 & 5) and written detail specification (7). Clients’ money and time are involved so you need to make it “their thing”. Second, use good, real-time and stable collaborative tools like Google docs or Office 365. Do not use the attached office files (docx, xls) for circulating the project plan. Do not use email for task handling and bug tracking. They create knowledge silos. Do have a centralized system for all of your work items (JIRA, Basecamp, Trello, and Asana are good starting points for project management). Enable all of your docs and work items visible and editable for the whole team.

7. Do you have a spec?

Leonardo Da Vinci famously stated that projects are ⅔ planning and ⅓ executing. This is especially true for software projects. Due to their complexity, every function needs to be broken down and specified. As detailed as possible. But most importantly, stakeholders, clients, project managers and developers need to be in sync about what they are building!

We don’t need an accurate document, we need a shared understanding! (@JeffPatton)

Tips for your team: Again, start with Google docs or some other collaborative tool that clients can access and comment upon. Organize in-house estimation sessions with your team on project specifications prior to project start (right in the selling phase). Developers and managers need to work together on project specifications. Use Team Playbook from Atlassian to properly plan various project discovery meetings and workshops. Some of them are useful to get you started and find your way of properly defining project specs:

– Contextual Inquiry
– Customer Interview
– Empathy Mapping
– Experience Canvas
– Journey Mapping
– Problem Framing
– Project Poster
– Trade-off Sliders

8. Do programmers have quiet working conditions?

Programmers really hate open floor plans. The idea that open spaces bolster collaboration and communication is true… but on Wall Street trading floors. Not in a digital team where programming is a solitary activity, and developers don’t benefit from overhearing conversations.

The more things you can keep in your brain at once, the faster you can code, by orders of magnitude.

When we organized our workspace, we were lucky that our house had several rooms and separate spaces to accommodate around 15 – 20 core team members. We have a main kitchen, garden BBQ and central meeting room, but these are not used for production. Design and development rooms are capable of holding 3 to 4 colleagues and we think this is a good approach to working with your teammates. Remote work is possible in Neuralab and we mainly use Google Hangouts for collaborating on projects. For us, hangouts are better than Slack as clients understand (and know) Google apps… and it’s not awkward when we invite them to chat or video call.

Tips for your team: Limit room occupancy to max 5 team members. Use panels and additional modular walls if you don’t have normal office rooms. Make communication asynchronous. Use chat, email and project management tools to communicate important project moments. Avoid telephones and unnecessary meetings that only generate noise without substance. Written communication is gold in software development as it can be used on a need basis, copied, sliced and analyzed. Also, written communication does not break the “train of thought” for developers, content writers and designers (as telephones, chit-chats and meetings do)

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

This is also a no-brainer. Use any tool that will help you in your job and don’t be a cheap asshole about it. The answer lies in pure economy. If you charge 100 USD per hour, then it would make sense to pay for the tools that provide you with the best possible means of writing your code.

Let’s break down the monthly cost of tools one person needs in a modern web development team:

– 50 $, Adobe Creative Cloud
– 25 $, Invision for gathering client and teammates feedback
– 10 $, JIRA for project management
– 10 $, Google Apps with unlimited Drive storage
– 10 $ AWS cost of development virtual machine (ec2, s3, ebs…)
– 00 $, Atom, Gulp, Grunt, Git, Node, BitBucket, Browsersync, WordPress, Linux, MariaDB…

Tips for your team: For around 100 bucks, you can have the best tools for creating modern web applications. There are alternatives to these apps, but their cost is roughly in the same neighborhood. You will pay them off with one development hour every month. Let me repeat that, one development hour (but it will save you plenty).

10. Do you have testers?

Testing of applications should be separated from the developers who made it. It provides a fresh pair of eyes, combined with an objective point of view. Testers are not in love with developers’ code so they tend to scrutinize the application in a real and objective way. This is the reason why we test on several levels. First, we do internal testing where a group of people from the company is trying out the application and every user flow. After that, we also hire external testers via Fiverr to give an even more objective view on the app behavior. When the results are in, we fill up the backlog (point 4) and write up the JIRA tasks for the development team.

Tips for your team: test the application with your friends and family (This is a good starting point for doing proper QA). Use automated and fairly cheap services like BrowserStack for front-end testing. Use multiple Fiverr testers to broaden the scope of testing and received feedback.

11. Do new candidates write code during their interview?

We constantly test two types of assignments: databases & algorithms. Every Junior developer will go through it so we can get a glimpse of how the new teammate is thinking about architecture and needed code procedures. Most of the small coding subtasks are presented just to get the idea of how the candidate is thinking about object correlations and needed methods to handle data.

These tests are not a deal breaker. Hiring good people is a complex topic so we don’t limit ourselves to teammates that excel in these tests. They are more of an opener for deeper conversations.

Tips for your team: write down the plan for hiring interview on one A4 page. Every candidate should have at least 1 h of interview time and every candidate should have exactly the same hiring process. You need to make sure that everything is objective and that code tests are done in a repeatable and stable way. Only then you will be able to properly grade them. Use real-life code examples from your current projects as this is something you and your candidate can relate to. Use the existing technology and programming language that you’re hiring for. Don’t test PHP developers with Matlab or Haskel 😉

12. Are you doing hallway usability tests?

Luckily, we are situated in a house with hallways, staircases, a garden and a meeting room where you can chat, draw or comment on the best possible UX/UI. Hallway testing is integrated into the team, but not only for software development. We also test designs, interactivities, copywriting and even our content marketing efforts. We also take care that Google Analytics data is incorporated into redesign decisions so this type of knowledge is written in the DNA of a project.

Tips for your team: use InVision and Framer.js to build early prototypes. Use Google Analytics Data studio and Slemma to analyze interactivities and combine data from various channels. Test early and test often. You should start thinking about interactivities and function right in the wireframing phase, not just when the front-end is done. Check out Marvel app if you’re into building mobile apps. It will help a lot in the early sketching phases. The ones that count the most.