Funability, Part 4 – Processes Can Be Fun

Note: This post was co-authored by Chad Michel. The rest of this 5-part series can be found here:

Part 1 – What and Why
Part 2 – Leverage Your Leadership Roles
Part 3 – Maximizing Productivity
Part 5 – A Layered Approach To Quality

In the fourth part of our series, we will be building on the what’s and why’s of funability, how to leverage your leadership roles, and ways to maximize the productivity of your engineers by covering how development processes can incorporate more satisfaction into daily work and contribute to a rewarding workplace culture.

Design Identity (Have One)

The concept of having a consistent design identity goes back to the early days of Don’t Panic Labs. Since the beginning, our vision included having several projects going on simultaneously. This meant finding ways to avoid treating each new project as a unique design effort. We needed commonality.

When done properly, the design methodologies employed (e.g., object-orientation, service usage, micro-services, IDesign concepts) in every project should be so similar that they look like they were all created from a single mind.

In his classic book The Mythical Man Month, legendary software engineer Fred Brooks said, “I will contend that Conceptual Integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.”

In other words, given that we are building software that (hopefully) will be extended and maintained for years, having a system that has no shared or controlled design or, worse yet, where all design decisions are left to individual developers, will surely lead to software “rot.”

Clearly, there needs to be some sort of design. But too often, especially in the startup world, there is a push to move fast and skip the design step. While this may feel good at the beginning because it keeps the forward momentum, whatever benefits you think you are realizing will end quickly.

Martin Fowler addresses this exact phenomenon in what he calls his Design Stamina Hypothesis (see below).

In his experience, as well as ours, it doesn’t take you long to begin reaping the benefits of having good design. See that point where the “good design” and the “no design” lines cross on the “design payoff line”? That usually happens in just a matter of weeks, not months. This is why we believe that if you’re working on a project that’s going to last longer than a few weeks, you’re better off investing in a software design/architecture exercise. That relatively little bit of effort to make the experience of working on that code more enjoyable.

To sum up, here are some of the benefits we’ve realized by having a consistent design identity:

Testability. Perhaps we’re stating the obvious, but quality assurance is made much easier when a shared design identity exists. If several systems share the same methodologies, they naturally become much easier to test. A sort of rhythm is found by the engineers. They become instinctively aware of where possible problems may arise. They build the system with this knowledge in mind, avoiding many pitfalls that would typically ensnare a one-off system. But if a problem does arise, troubleshooting is typically quick. This keeps the project moving forward. It also keeps product quality high. And those make for happy engineers.

Flexibility. Not only does this mindset save time, it also makes it easy for environments (like ours) where engineers may be moved around. By using shared programming models, methodologies, processes and patterns, it’s easy for us to take an engineer from one project and put them on another. We only need to spend a short amount of time showing them the architecture diagrams and discussing which services are implemented. We then send them on their way. This makes for a very efficient environment that consistently keeps the “getting started” frustrations to a minimum.

Repeatability. And this has helped us throughout our diverse portfolio of projects. Whether it is a motion capture and 3D imaging unit that tracks weight-training athletes (EliteForm) or a data-heavy infrastructure management system (Beehive Industries), shared design processes have helped move these projects much faster than building two separate products from the ground up.

Practice Test-Driven Design

In a previous life, both of us worked together at an e-commerce company. The core software was not developed with funability in mind and it was – for lack of better adjectives – a train wreck. It was difficult to maintain and it was difficult to deploy. Basically, it was not enjoyable.

We came to the realization that a rewrite was required so it could be more efficiently maintained in the future. While we initially didn’t want to take this project on, it became apparent very quickly that it was becoming one of the most enjoyable experiences we’ve ever had. We took what we had learned in the past and thoughtfully constructed this new system. We made unit testing a priority and we had numerous tests around the entire code base. We were feeling good about it.

And we needed that confidence because one day, the old system just collapsed. It was a goner. So that seemed as good of time as any to roll out the new system. And it was a fairly painless rollout, but that doesn’t mean it wasn’t scary. We didn’t think that we were ready for a rollout, but when we considered the number of tests we constructed along the way, it instilled a lot of confidence. So from that day forward, we’ve been sold on the idea of test-driven design.

One reason why we believe so strongly in test-driven design is because it forces consumption awareness in the code, because you, as a test writer, are the first consumer of a class/service/method. It focuses you on the interface rather than the implementation. And when you become the first consumer, it makes you consider aspects you might not have before (such as decoupling the code to make it more testable and facing areas head-on you may have otherwise skipped because of its high level of difficulty).

Implementing unit tests forces the engineer to be more empathetic about the code they are writing. It’s perspectives like that which makes life easier for the people who will be maintaining the code in the future. When you have to describe the intent of your code, you can be led to think differently about how you’re going about it. Sometimes the only way to really get your point across is to write example code. Even better. Taking time to document as much as you can lay the groundwork for an enjoyable system later. One of our favorite developer maxims holds true for tests as well as the code itself: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”

Testing also allows you to run “what if” games around your code. If you’re planning wide-reaching changes to your system, testing helps you proactively assess the impact. These exercises can be quite fun, especially if you’re the type of engineer who obsesses about performance and efficiency.

There’s Still More

In this post, we covered the importance of processes that help achieve funability through various design processes. In our next post, we’ll cover how various layers of testing can produce quality software and – in turn – provide funability for the team.

 

 

This post was originally published on the Don’t Panic Labs blog.

/0 Comments/by

Funability, Part 3 – Maximizing Productivity

Note: This post was co-authored by Chad Michel. The rest of this 5-part series can be found here:

Part 1 – What and Why
Part 2 – Leverage Your Leadership Roles
Part 4 – Processes Can Be Fun
Part 5 – A Layered Approach To Quality

In this third part of our series, we are covering the importance of creating environments that maximize the productivity of your engineers. Here we are specifically talking about aspects of our culture and environment that are separate from the more familiar developer productivity strategies related to software design/construction and agile methods.

Of all the strategies we are discussing in this blog series, these are strategies we didn’t have in mind before building Nebraska Global and Don’t Panic Labs. It reminds us that we never really “arrive” as an efficient, fun, and productive software development culture. There are always things to learn and try, and it is important to always be reflecting, evaluating, and implementing new strategies to improve the level of funability in our organization.

Protecting Schedules

It’s easy to fall into the trap of thinking that all time is created equal. Two 30-minute sessions produce the same quality of output as one 60-minute session, right?

Nope.

One of the hard lessons we learned in our early days was the value of keeping schedules free so engineers could have long interrupted sessions where they could just work. The concept of “unmuddying” schedules wasn’t even on our radars.

In the early days, we would schedule meetings willy-nilly. If someone thought a team should gather to discuss a particular topic, we put it on the calendar. But these meetings didn’t occur just once a day; they became frequent, a bad habit.

As you can imagine, our days became a mess very quickly. We had the early-company urgency that kept fires lit under us and we were okay with it. Until we recognized the cost.

One day we woke to the realization that our engineers were left with only small slices of time to work on their projects. Their day was relentlessly divvyed up amongst all of their various meetings. It had become apparent this was not sustainable. We were robbing our engineers of solid blocks of time where they could knuckle-down and be productive.

We used to make excuses, telling ourselves we were good multi-taskers and could just deal with it. But that just wasn’t the case. Our engineers would find themselves returning from yet another meeting and spending about 20 minutes just getting back to where they left off. The constant interruptions were hurting our efficiency. The cost was just too great.

So we stepped back and analyzed the situation. We found that if you give your engineers 4+ hours of uninterrupted blocks of time to focus, they will be more productive, they will enjoy what they’re doing more, and the team will have better software to show for it.

To make sure we don’t fall back into our former meeting-heavy mindset, we operate with the basic plan that we only allow meetings in the mornings. If some emergency comes up and we need to get together, we’ll make time for it (but it had better be a BIG emergency). In the end, we must be strict in protecting the time of our engineers.

As a graphical before-and-after illustration, below are two calendars. The one on the left belongs to Doug. This is typical of what our engineers used to see before we changed our approach to meetings. As you can see, there’s very little time for real work. It’s a productivity disaster. The calendar on the right is a typical calendar today. Sure, there are a couple irregularly scheduled meetings. But for the most part, most of the day is in the clear.

For some additional thoughts on scheduling, we recommend Paul Graham’s blog post Maker’s Schedule, Manager’s Schedule.

We understand that making a change of this type requires a lot of company and culture buy-in. This may not be something you can just “flip a switch” and make happen right away. It’s a real adjustment. But how we run our schedules at Don’t Panic Labs is proof that it works and we are now strong advocates for it.

Local Resources

Another approach to software development that we hadn’t considered in the past was making sure the engineers could run every aspect of their projects on their machines.

Oftentimes there are additional resources that reside in other locations. Perhaps this is a service on another server or a big SQL database box. But if the engineers are spending their time connecting with many “outside” resources, that is time not well spent and can quickly lead to frustration (the opposite of fun).

What if the entire application stack was available on the engineers’ local machines?

This is what we asked ourselves, and then sought the answer by trying it out. In short, it made a world of difference.

For one, your engineers can more quickly develop their projects without spending a bunch of extra time configuring the required remote components. Whether it’s a mock service or a local database, having everything local makes it a lot faster to get up and going.

This approach also creates an environment where engineers aren’t vying for a limited number of resources or having to work around configuration changes/differences on the shared resources. For example, if a centralized SQL server is used for the development team, one developer’s changes that require a database modification will be difficult to manage on a shared server without coordination with other developers to ensure they will be able to test as well. This extra “configuration management” is burdensome and frustrating as a developer.

Achieving this ability to develop and test locally (including database resources) may sound hard but we have been able to achieve this across all of our product platforms in Nebraska Global. It does take some advance planning and adherence to this ideal (including finding the right tools to make it smoother), and we have found that it actually drives some design decisions about our applications that enable/preserve this ability. It also requires the ability to do iterative database design with a solid, script-based, configuration management process for database design and deployment.

As almost a bonus, having as many of the project’s resources locally available also gives engineers the flexibility to work wherever they want. They’re no longer tied to our internal network. They can take their entire project with them on their notebooks and work at home, at another off-site location, or on our deck. This is funability at its finest.

Is that it?

We’ve learned quite a bit about making opportunities for developers and engineers to maximize their productivity. But we’re still not done. We still have more to cover.

In our next post, we’ll show how design and layered quality processes contribute to funability.

 

 

This post was originally published on the Don’t Panic Labs blog.

/0 Comments/by

Funability, Part 2 – Leverage Your Leadership Roles

Note: This post was co-authored by Chad Michel. The rest of this 5-part series can be found here:

Part 1 – What and Why
Part 3 – Maximizing Productivity
Part 4 – Processes Can Be Fun
Part 5 – A Layered Approach To Quality

In our previous post, we covered how we think software development shops can instill some sort of culture and processes that help their teams realize the motivations that got them into this industry in the first place. We call it “funability”, and break it down into seven major components:

  • Frequent delivery of value to customers
  • Being part of a team
  • Maintainability of systems
  • Effective management of technical debt
  • Consistent quality of product releases
  • Productivity and efficiency of the developers
  • Sound software design

But once we have it defined, what do we do next? While it may sound like most of what we emphasized can be managed through office layout and agile processes, there’s actually much more to it. But at the same time, we don’t want to diminish the importance of these two factors. So let’s start with them.

Office Layouts

Who doesn’t want a cool office? Many of us started out in very strict environments, so any kind of laid back environment is a welcome change. But even developers who have only worked in the 21st century, t-shirt and jeans shops are not achieving their full potential with simply a loose approach to dress-codes and office aesthetics.

This isn’t to say they aren’t important. We feel that our space – its layout, amenities, and other flourishes of fun – definitely contributes to not only our culture but our effectiveness and productivity. It increases socialization among the engineers, which is essential for collaboration. Our recruiting efforts are also made easier with our unique space. So because of this, we can’t understate the impact physical environment has on getting the right people on your team (and keeping them).

But the spaces in which we work can’t be everything.

Agile Processes

Agile is not a silver bullet. Let’s just get that out of the way.

Don’t get us wrong, we believe that it provides one of the best (if not the best) approaches around which to center most software development. It allows our teams to operate lean, fast, and efficient, which are three essentials for nearly every shop but especially those in the startup world.

Like we’ve said before, our use of agile methodologies is not a dogmatic adherence. Rather, we leverage the basic principles and adapt them into our processes when they’re most applicable. And it’s this kind of flexibility that makes us as effective and productive as possible.

But agile methodologies alone are not a magic pill for solving all of our difficulties. This is due to the ever-increasing complexity of the problems that we’re trying to solve with our software.

We came up with this simple table to paint a more concise picture of which aspects of funability are addressed by office layouts and agile processes. As you can see, there are plenty of gaps that need to be filled.

So how do we fill these gaps? Our first strategy is to look at the key roles within our development team that can significantly impact funability.

Key Team Roles

Taking time to reflect on how our teams are thought of and organized has really helped us. It gave us time to be honest with how we can most efficiently function at every point throughout the software lifecycle. From scoping to deployment, we have a really good idea how everyone works together. And by just having this bit of knowledge is essential to our funability.

As you can see, we place quite a bit of emphasis on two main roles: Developer Leads and Project Managers. While obviously everyone on the team is important, there’s special emphasis placed on these two roles. And for good reason.

Strong Developer Leads

Most development shops have the position of “Lead Developer” or “Senior Developer” on their teams. These are usually engineers who (almost always) have the most development experience, and hopefully have great leadership qualities and the willingness to mentor younger or less-experienced developers. But we take this a bit further.

For our “Lead Engineer” role, we give them the duties of the traditional “leader” role and include these responsibilities:

  • In charge of maintaining conceptual design
  • Maintains the “big picture” of the product
  • Responsible for the performance of the product
  • Ensure engineers are testing their code

We’re sure that most Leads or Seniors at one time or another have been stuck helping others get Visual Studio set up, guide them in getting familiar with the particulars of your development environment, and other menial “getting started” tasks. We’ve all been there at some point. And while those just come with the position, that is not what we’re talking about. We task our Leads with being the “vision holder”. We need to have strong technical oversight throughout the lifecycle of the projects. Without that, it’s too easy for engineers who are in the code all day to stray from sound principles, established design criteria, and best practices.

So when the vision, design integrity and principles are maintained, funability is increased. Avoiding as many violations of these objectives as possible helps pave a better road forward. Nobody is going to have fun if the project takes a turn down the wrong road and additional work (or re-work) is necessary. We need to put greater emphasis on fixing the broken windows as soon as possible and avoiding breaking them in the first place.

Strong Project Management

The other essential role we have at Don’t Panic Labs is that of Project Manager. They perform tasks that are just as important as the engineers. Without them, we sometimes wonder how far any of our projects would go. Many of their responsibilities include:

  • Central communication for the project
  • Tight coordination with Lead Engineer, UI/UX, QA, and product manager
  • Decision tracking and documentation
  • Release plan development
  • Task/action item tracking
  • Project status monitoring/reporting
  • Project health monitoring/reporting
  • Information/decision coordination
  • Conducting retrospectives
  • Management of external communications
  • Lead daily standups
  • Keep sprint planning to less than an hour in length

But what we consider to be the primary role of the Project Manager is that of “process facilitator”, and this makes them key to funability (although we’re not sure they always think of it as fun). They are tasked with keeping track of all the little project details so that the engineers are freed up to focus on their projects. Once again, it’s all about clearing the road ahead for the developers and removing unnecessary mental weight.

What’s Next

Here we’ve covered how you can use your office space, adhere to your processes, and leverage your leadership roles to increase funability for your teams. But there’s still more.

In our next post, we’ll look at the importance of protecting engineers’ schedules and how that helps increase funability by providing long stretches of uninterrupted time to focus.

 

 

This post was originally published on the Don’t Panic Labs blog.

/0 Comments/by

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.

/0 Comments/by

Product Development at Nebraska Global / Don’t Panic Labs

,

Last Thursday we hosted an open house as part of Agile Lincoln’s monthly meetup. We were blown away by how many people showed up to see who we are, learn what we’re doing, and hear me talk about our approaches to software engineering.

Since then a number of people have requested the slides and recording of the presentation.

Special thanks to the Lincoln Agile Group for providing the Periscope recording!

If you have any questions or want to learn more, we’d love to continue the conversation. Leave a comment below or email us at [email protected].

You can also sign up for our monthly newsletter to keep up with what we’re reading, writing on the blog, and local events.

 

 

This post was originally published on the Don’t Panic Labs blog.

/0 Comments/by