By Najaf Ali
We’re good at building software, but we won’t make prescriptions about how you should do it. In the years since Happy Bear Software was established, we’ve noticed some recurring themes about what helps to build better software and what doesn’t.
We want to outline these here for a number of reasons.
First we want to characterise our company in comparison to other developers and to our competition.
We also want to give our clients and potential developers a good idea of what to expect when they go on to work with us.
Finally we want to use this as an internal compass for day-to-day work. We want it to act as a guide to what to focus on, both when things are going well and when things are going badly.
The closer we are to the user, the better
Our clients get the most value out of our services when we have direct access to users or to the closest people to them (e.g. support staff). Getting direct feedback from users, screen-sharing with them, discussing their problems in software over IM or video call, and otherwise engaging with them as we work on the code results in the most immediately valuable software we create.
Our planning work can be communicated in the form of roadmaps, personas, journeys, stories, acceptance criteria, and other formats. But ultimately, engagement with users is the activation energy for the entire software development process. It makes us more motivated, more likely to build the right thing, and more able to build it faster.
We are a team of professional developers
Just because you can make a good omelette, doesn’t mean that you’re ready to work in a professional kitchen. There is a difference between treating programming as a skill and treating it as a profession.
For us the difference is that we don’t just want to help our clients build software that they need right now. We also want to help our clients make good decisions about building software.
This means being able to see down the road for them and try to help them avoid or mitigate problems. It means maintaining a minimum standard of quality, especially when no one appreciates it, in all of the software we build for them. It means making decisions about how and when to safely relax those standards when an immediate business case is apparent.
When it comes to software development, we’re the backstop to the client’s technical team. They will often look to us for guidance when making technical decisions and it’s our job to provide that guidance, with thoughtfulness and empathy.
Shipping early and often is almost always a good idea
Shipping early and often means that we make the cycle from defining requirements to putting changes in front of production users as short and painless as possible. It means deploying multiple times per day instead of in big releases. It means pushing unfinished work (perhaps behind feature flags) to production on master rather than have long-running branches that aren’t deployed.
Shipping early and often allows users to give you feedback much earlier in the development process, saving time and effort that might otherwise have been wasted building the wrong thing. It allows you to deal with one or two deployment problems at a time rather than all together when deploying a huge release with multiple branches. It allows the rest of your organisation to clearly see the value that your development team brings because they’re shipping changes daily instead of weekly or fortnightly.
Shipping early and often requires a mature, pragmatic testing culture in your team, a build server, and an acceptance that sometimes things are going to be on production that aren’t perfect (they wouldn’t be anyway, but you’ll have to deal with it a lot more often). Do it right though, and you end up with a more motivated team, shipping more of the right software to production at a much higher rate.
It’s our job to know the details
We’re a web application development consultancy. We are experts in web application development. It’s our job to know the details of as much of the above as we can. It’s probably impossible for any one of us to be experts in all of the above. But between us we cover a significant percentage of it. When a problem we’re unfamiliar with comes up, we can draw on our team’s knowledge, or at the very least go to primary sources to fill in the details we’re short on. Within the sphere of web application development, it’s our job to be a guide for our clients.
Pro-active, generous, effective communication by default
Pro-active, generous, effective communication is the absolute minimum required to get the right work done for our clients in a way that they’re happy with. Even if we build the exact software they want on the first attempt, they will be much happier about the engagement with us with good communication.
Sometimes this communication will simply be the firehose of our activity from notifications in Slack from GitHub/Trello etc of our work. It might also include summary status updates about what got worked, what got shipped to production, what problems came up, and what you’re planning on working on next. It has to include regular conversations with our clients where we discuss what needs building, how to build it, how to test it, and feedback on what we made. Communication can take the form of video calls, emails, sketches, wireframes, recorded video, plain text, user stories, acceptance criteria, or any other format that is appropriate in the given context.
This communication has to happen at all stages of the development process. It has to happen both on the way up and on the way down the hill of uncertainty . That means talking about the problem you’re trying to solve, determining a preliminary solution, getting feedback on an approach to building the thing, pairing/getting reviews when actually building the thing, communicating that you’ve shipped the thing to production, telling people how to test the thing you shipped, and starting all over again as you iterate on feedback.
This level of the basic communication is the carrier wave along which all of our work is transmitted. Without it we don’t know what to build, we don’t know if we’re doing a good job, and we ultimately can’t provide value to our clients.
We only use “best practices” in appropriate context
Our industry is obsessed with “best practices”. We’ve observed millions of pounds worth of damage when techniques concepts were applied in an inappropriate context. This happens sometimes because of a genuine misunderstanding of the practice in question, or simply because the developers on the team crave novelty.
We try to apply practices that are appropriate for the context that we find ourselves in. That means figuring out what context a practice is supposed to be used in and trying to find similarities between that context and our current situation. We also want to be able to make concrete predictions that we can be wrong about regarding the practice. If we do X in this context, we should get A, B, and C outcome.
Some practices are applicable in a huge range of contexts so we do them by default (e.g. iterative development). Others are applicable in so small a subset of contexts that we never use them at all (e.g. microservices). But for any one of them, you can expect us to be able to reel off a list of predictions of two or three concrete benefits of applying them in this context. We have reasons for doing things, or we don’t do them.
Building software and building it well is a huge topic that has had millions of words written about it. The above is a distillation of our experiences building software for our current clients, and forms our approach when working with new ones.
If part or all of this sounds congruent with your approach to building software, there’s a chance that we would work well together. If that sounds like it might be of interest, get in touch at [email protected] and someone from the team will be in touch to set up a meeting to discuss further.