Funability, Part 1 – What and Why
Note: This post was co-authored by Chad Michel. The rest of this 5-part series can be found here:
Part 2 – Leverage Your Leadership Roles
Part 3 – Maximizing Productivity
Part 4 – Processes Can Be Fun
Part 5 – A Layered Approach To Quality
We’ve been in the software business for quite some time. Between the two of us, we have nearly 45 years in. That’s a LONG time, especially in this relatively young industry. So when you’ve been part of a profession for that long, it can be easy to forget what initially attracted you to it.
We bring this up because we believe that there are some fundamental aspects of our industry that are missing and they’re causing us damage. Maybe not initially, but they’re slowly hurting us over time.
And if we’re hurting, our products can will suffer.
As with so many industries, we in the software development sector too often reduce our workforce to the lowest common denominator of function. In our industry, that means turning our workers into little more than robotic programmers who just pound out code all day.
Add that feature. Fix this bug. Death marches towards impossible deadlines. And all this to what end? A check mark placed next to another hastily-implemented new feature?
There is more to this, right? There is a way to bring some semblance of life to the desert of code >test >release->fix->test->release, right?
Yes, there is! Of course we are talking about fun.
But we aren’t talking about video games, free meals, beanbag chairs, and indoor slides. While those can be fun, we believe that “fun” needs to go deeper. We’re talking about finding true enjoyment in the work itself. Because if we find honest satisfaction in what we are creating, how we are tackling problems, and why we are changing something for the better then we can consider “fun” the curtain that – when pulled back – reveals a rarely-achieved level of personal and professional fulfillment.
While starting Nebraska Global and Don’t Panic Labs over six years ago, we knew that we had to take a different approach to software development. Anybody can build out a fun workspace, but we knew from our past experiences that we needed to go beyond the creature comforts typically found in the startup world. We needed to identify the real, soul-feeding fuel that gets us out of bed every morning and drives us to get our best selves in front of the day’s challenges.
To do this we had to examine where pain points existed within our daily routines and get them out of the way so our engineers could focus on projects and enjoy the journeys through them. But to find that seed of gratification, we had to remind ourselves why we originally chose this career.
As we thought back through the years (no old-age jokes, please) we came up with this list of motivations that informed and drove our initial passions for software development:
- Rapid return on our efforts
- Work on tough problems
- Build tools that people use
- Enrich our lives
- Build something innovative
- Impact lives
- Save money / create wealth
- Automate complex activities
These are what we wanted to pay attention to, make them the focus of our daily work. In other words, we wanted an environment where what we enjoy outweighs what we loathe.
Too often we found that our days looked more like this:
So as we were thinking through all of this, we came up with a term that describes it: funability. We defined it as “the measure of how well our culture and processes enable us to realize the motivations that got us into the business in the first place”. Since we have so many other “-ilities” in our work lives (scalability, maintainability, etc.), we felt this word made sense in a clever sort of way.
What Contributes to Funability
As soon as we defined what we wanted, we had to figure out how we were going to keep it at the forefront of our culture and daily practices, and keep our engineers engaged in our culture, company, and software development processes. We came up with seven points that we felt best encompassed our philosophy of funability.
Frequent Delivery of Value to Customers
This comes from our agile-inspired development environment. Earlier in our careers, we were pushing out releases only two or three times a year. It was a slow build-up that, in many ways, was made slower by less-than-ideal practices. And when you build up that much code over that much time, it can create a lot of pain before it even makes it out the door. There was a lot to pull together. Through that, we found that if we can increase the frequency at which we deliver fresh bits to customers we not only increase their satisfaction, but our own satisfaction too.
Being Part of a Team
Obvious, right? Maybe not so much in some environments. In the military, we have the term esprit de corps, a feeling of pride and a common loyalty among members of a group. We believe that with a spirit of mutual accountability among the team members we can be freed up to run a very flat organization. There are no managers; the teams run themselves. And it’s that kind of empowerment that deeply instills a feeling of ownership and personal achievement, which is tough to create in other ways.
Maintainability of Systems
Here’s an aspect that is probably easier said than done. Building software that can be easily read, understood, and debugged is a big deal. And once it’s done right it will reap benefits for many versions down the road (if the initial principles are upheld). Making it easy for engineers to jump right into a system and quickly understand the impact changes will have is really quite valuable.
This robust base from which a system can grow and change gives team members that sense of “yeah, we’re getting stuff done”. And as I’m sure we can all attest, that beats the alternative of spending what can seem like countless hours deciphering what others have done in the past.
Effective Management of Technical Debt
Ah, technical debt. It will always be with us, but we can limit its drag on our projects by first recognizing when choices will lead to an increase in our level of technical debt. Typically (and at the most basic level) this means not implementing features the quickest way possible but taking the time necessary to understand the tradeoffs that may lead to a less than optimal design. In the ideal case we can find a path to avoid taking on the debt but when this cannot be avoided we need to at least acknowledge the risk and plan (e.g. via a new backlog item) for how we will deal with it down the road. Maybe the most important part of this is the conversation and the shared understanding by the team of the choices being made.
Consistent Quality of Product Releases
Back in the early 2000s, we (along with a few other DPLers) had developed and were managing an eCommerce platform. Releases were done only a few times a year, and for good reason: we were on pins and needles the whole time. Would it work? What would break? How seriously would it break? How quickly could we fix it? It was a very stressful time that to this day still gives us anxiety by just thinking it about.
These past headaches are one of the driving reasons why we approach releases the way we do today. The importance of having smooth releases cannot be overstated, especially when you’re updating mission-critical systems. Living in dread of release days does not make for healthy work environments.
Productivity and Efficiency of the Developers
One of the best things we can do for our developers and engineers is to reduce their distractions, “clear the road” so to speak. By doing this, we’re giving them enough time to get into a problem and work it out. Allowing them to be constantly interrupted by numerous meetings or additional side-tasks just creates frustrations or, even worse, less-than-optimal solutions.
There are a variety of things we do that fall under the category of productivity and efficiency: the role of project management, how we physically organize the office space, the structure of our teams, and the way we design the software itself.
Sound Software Design
Maintaining some sort of consistency in your conceptual system designs is key. Providing consistency across your entire platform is what makes flexibility possible within your team. When everything is designed and developed using the same philosophies and concepts, moving team members around to different projects becomes a lot less risky and inefficient. We believe this is one of our strengths at Don’t Panic Labs.
For example, if a project requires a short burst of extra development muscle, we can augment a team with additional engineers very quickly. By keeping our methodologies consistent, it doesn’t take much for the “new guys” to get up to speed on the project. They can get going very quickly.
Consistency also prioritizes simplicity over cleverness. Sometimes a clever approach to a problem can be fun, but most times it adds undue complexity which can act not only as a speedbump for someone needing to learn the code base but also cause problems when new features are implemented. Our discipline in this area has also helped us scope projects for estimation. Nearly everything becomes more predictable when we stick to known and repeatable processes and patterns.
This is the bedrock of our culture and is something we’ve been doing since Day One. We’re not dogmatic about much, but this one may be the closest thing to religious adherence we have.
Now What?
In this post we’ve covered what we see is a fundamental problem within the software development industry and how we’re addressing it in our immediate world through the concept of “funability”. But what strategies and techniques can be implemented to increase the funability of development shops? Stay tuned for our next post for our recommendations.
This post was originally published on the Don’t Panic Labs blog.
