By: Chris Greacen - 10/19/2023
I recently wrote a post on Lab Zero's blog on the topic of recognizing sources of technical debt. This caught the attention of one of the organizers of the Bay ALN meetups and they invited me to present on the topic.

I put a brief talk together based on the outline of that blog post and delivered it the other night. I think I can embed a couple slides from the deck I used...

The presentation followed this path through the story.

• Intro, caveats
• Tech debt background
• Recognizing trouble
• Two common sources
• Recognizing progress
• The real casualty
• Two questions for you

Give this a listen if you're curious about how this went or if you're interested in Technical Debt.

By: Chris Greacen - 09/01/2023

Hope everyone is all set for a good Labor Day weekend. I wanted to share some updates from the Lab Zero Innovations Inc. team. A couple new posts on the blog hint at some of the recent work that the team has focused on: application modernization, performance improvements, managing technical debt. Take a peek:

I shared some thoughts about the two most common sources of technical debt: https://labzero.com/blog/two-most-common-sources-of-technical-debt

Jeffrey Faden shares his experience in modernizing a React.js application: https://labzero.com/blog/upgrading-an-ancient-react-application

Travis Gaff shares a great way to get server performance data into your browser's developer tools: https://labzero.com/blog/server-timings-rails-performance-metrics-in-your-dev-tools

Let's stay in touch!

http://labzero.com

#technicaldebt #reactjs #applicationmodernization #developertools #applicationperformance #blog #fricassee

By: Chris Greacen - 08/28/2023
People say "technical debt" like it's a bad thing. But those who are serious about software development know that this game is all about managing technical debt. Technical debt is a natural part of the landscape in any software development team’s world. It's neither good, nor bad. Yet when trade-offs are mismanaged, technical debt is likely to cause your productivity to grind to a halt. For people who hit that point and wonder why - there should be no mystery about what causes technical debt, the answer is right in front of you.

What is technical debt?

We can thank an early agile-manifesto-ist Ward Cunningham for the term"technical debt" which is a fantastic metaphor for this dynamic. Technical debt, code debt, or design debt functions the same as financial debt: a team can take a shortcut to deliver something quickly, but the short-term advantage of that short-cut can make future work harder. The team gets a convenience in the short run, but has to pay it down with some interest later.

Not all technical debt is equal

Every team at every company regularly makes trade-offs about incurring debt to get something done, then hopefully cleaning it up and refining it afterward. You get a quick win, then you do the work to strengthen or refine your short-cuts. Where this gets dangerous is when it's not a conscious or intentional choice - a team can stumble into a situation where previous decisions they've made have a disproportionately high impact on the work they're doing today. They've built to their best understanding, done their best efforts, but somehow they are still bogged-down. If you find that your team seems stuck in firefighting-mode, unable to deliver new features, facing quality challenges, you may have unintentionally ended up with technical debt.

Where does technical debt come from? (spoiler alert: it's your team)

If you're deep in it, you may be wondering how did we get here? There's a lot of writing online about the causes of technical debt. I'm sure you've read them already. But when you boil it all down, unintentional tech debt comes from two sources: your engineers and your product managers.

Your engineers contribute to technical debt

If your engineers lack the experience and skills to manage complexity, to refactor effectively, to advocate for refactoring/automation/re-architecting, they will build more than you need and have a hard time maintaining it. They may not have the discipline to regularly review, refactor, test, and remove the junk.

• No standards
• Not reviewing code
• No test automation
• No regular refactoring
• No regular re-architecting
• No evaluating new tech or libraries
• Not helping product managers understand what's needed
• Not advocating for process

Your product managers contribute to technical debt

If your PMs aren't effective with stakeholder management, if they engage in deadline-driven prioritization, if they have poor collaboration with technical roles, lack of clarity in what customers need, lack of clarity in what the business needs. These all conspire to let your teams write code that does't serve the business.

• Saying yes to your CEO's hairbrained idea
• Setting a string of date-driven milestones
• Being unclear on what your customers really need
• Not working to solve a measurable problem/solution
• Saying no when your engineers advocate for time to refactor/rearchitect
• Saying yes to big bang change

But wait, there's more: technical debt == design debt

Designers face challenges of managing complex technical assets (Figma), contributing to product development, and driving learning efforts to get closer to users. In our experience helping companies develop and deliver software products, we've seen how this kind of trade-off can create a similar compounding-interest with the design effort for a product. People love to start building as quickly as possible and inevitably build something based on assumptions. Maybe they get lucky and their assumptions are good enough to work with - more likely they will miss the mark with their customers. When they get around to learning what their customers really need, they will begin to understand the real effort that's needed.

The impact of technical debt

Each of these things in isolation might not have a big impact on your planning or your business. But in aggregate they'll start to show up. Have you seen something like this: defects piling up, poor application performance, poor UX, reduced customer satisfaction, your teams spending time on manual tasks rather than automating their work (driving up operating costs), simple work carrying too much risk (which nobody wants to take), customers preferring to talk to someone on the phone rather than use your website. The obvious end result is massive waste from friction in delivery and lack of capacity while everyone is fighting fires.

A less obvious casualty is your understanding of the cost of development. My personal peeve about the software development world is that very few teams have clarity on the value of what they're working on. The value of our work needs to incorporate the costs of development. When the costs of development are obfuscated by technical debt, it's very hard for a team to establish clear priorities and make effective tradeoffs.

Solving technical debt challenges

There is no one-size-fits-all solution - everyon's situation is different. We often hear teams lament that they are too busy to get help, so solving this isn't going to be straightforward. Without getting too deep into the weeds, you can see that the only way out is by changing practices that your product and engineering roles lead. A healthy approach to managing these trade-offs include regular reviews and refactoring, prioritizing this work that incorporates learning, maintaining high visibility into debt- generating trade-offs, and relying on partnership between engineering and product management in building your roadmap. Want more specifics to help tame and manage technical debt more effectively? Re-read the bulleted lists above and change all the "nos" to "yesses", and vice versa.

How are you managing these two common causes of technical debt in your org?

This post originally appeared on labzero.com.

By: Chris Greacen - 03/08/2023

The Lab Zero team has seen plenty of the good, the bad, and the ugly in the years we've been working in the software development world.

In this and the next couple videos, I'll talk about the 'bad' highlighting some of the lies we tell ourselves. First on my list is the 10x engineer/developer - a mythical creature sought by many.

Have you worked with a 10x engineer/developer? What was your experience?

Hey, this is Chris with Lab Zero. In my last video I mentioned that the Lab Zero team has seen 'The Good, The Bad, and The Ugly' in working on software product development over the years. And in this and the next couple videos I want to talk about 'The Ugly' - and specifically The Lies We Tell ourselves in the software product world.

The first lie I'll talk about is the 10x engineer. Perhaps you've heard it? The Lie goes something like this: the 10x engineer is an individual who will come join your team and do 10 times the work of a normal mortal. They will spray ten times the lines of code all over your source code repository. They will move 10 times the tickets... And um we know that to be a lie, right?

Let's talk about the truth. The truth is: these are well-rounded individuals who can think clearly about complex problems. They are very unlikely to solve a problem with software, unless it's really clear that there's a solution there. They want to write just enough software, with just enough quality so that the problem gets solved - and they don't have to get a page in the middle of the night or get called into work on the weekend (or whatever, remotely).

The 10x developers that I know have people skills. And they are just as likely to be able to get a group of people together to solve a complex problem as they are able to do anything on their own.

They have no pride in the amount of code that they deliver, or the amount of lines of code that they check into a repository. If anything, quite the opposite! They're going to be proud of the lines of code that they removed from a repository. They want to be known as the people who are taking out the unused stuff -- refactoring to make simple and clear all of those parts of the application which are critical and important to your business.

These are people who do not want to save your company. They're going to look at the need for heroics as a problem. Frankly, your plan should be working. The fact that they have those skills -- great. But they don't want to be pulling those things out all day, every day, on the weekend, and at the night.

Have you worked with 10x developers over the years? What is your experience in working with them? Share your notes or your comments below. I would love to hear from you!

Oh, and call out anything that you think is baloney that I just told you I'll follow this up with some other 'Lies That We Tell Ourselves' soon so stay tuned.

Thanks, this is Chris with Lab Zero!

#10x #heroics #ugly #10xengineer #10xdeveloper #productivity #lieswetellourselves #lies #experience #engineer #developer #softwaredevelopment #team

By: Chris Greacen - 02/13/2023

One of our first big engagements still serves as a model for all of Lab Zero Innovations Inc.'s highest impact work. Our client was able to unlock a huge victory by bringing in a small #team capable of #designing and #delivering a high quality #software #product. Great things can happen when you pair a high #performing team with a huge opportunity and a solid rationale.

I'm Chris Greacen with Lab Zero Innovations I'm going to tell a couple stories this week about the things we've seen over the years designing and building software products for our clients. We've seen "The Good The Bad and The Ugly". But today we're going to start with the beginning: our first big project, our first real, let's say -- opportunity to operate as the team that we always dreamed of being. An effective small team drives big outcomes through the delivery of good software product.

It started in 2008. Our first client was a big name -- you've probably heard of them. They do genealogical services. They let you research your family origins.

Here I am at Pier 38 which is where our family began. You probably know this place, or at least some of the products that came from this place. Some very famous very big names sprang out of Pier 38. They're probably on your phone right now. Lab Zero is not one of those things...

But the product that we worked on in this particular case, our first one is a big well-known name. They had a problem: they wanted to go public. They wanted to expand their empire and grow their company but their team was already subscribed, already committed to a very aggressive road map. Still, Wall Street analysts did not like the fortunes that this company had. They were not giving favorable ratings to this company as they prepared for their IPO.

They had two big problems. Problem number one - revenue was tied to number of users (MAUs). And the number of users was flat! Had been flat for years! Unlikely to grow Revenue - that's a big No-No in your IPO world.

Problem number two - was their product was very skewed toward people who are well documented, families who are well documented through history. Some people live in places where there are records. And the whole product was based on gathering records and connecting records to your family tree. As it turns out, not everybody has well-documented family history for a lot of reasons.

Someone in the company had a brilliant idea and they said, well if we can build a product that compares people's genetic history -- everybody's got genes... If we can sell this product to our existing users and decouple our revenue stream from our user base, we may overcome the objections and have a very successful IPO.

And that's where we came in: designing and building a product that fits into their world of the existing product suite, fits into the existing architecture, fits into the existing value prop, and extends that value prop to a new area. It took guts for those people to do that. To plunk down a budget for it. To work with people who are known at least to the decision makers, but still like outsiders.

Radical success for everybody involved. They took a chance to grow and make something great happen and they needed a team who knew their stuff. And we were lucky to be in the right place at the right time. And we definitely knew our stuff.

Since then we've learned a lot more. I'll tell you about it in the next video. Thanks for watching!

#productdesign #productdevelopment #strategy #ipo #wallstreet #genealogy