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
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.
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.
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.
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.
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.
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.
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.
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.
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?
#10x #heroics #ugly #10xengineer #10xdeveloper #productivity #lieswetellourselves #lies #experience #engineer #developer #softwaredevelopment #team
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.
#productdesign #productdevelopment #strategy #ipo #wallstreet #genealogy
Lab Zero Innovations Inc. started in 2008 with a #vision of our small team making a big impact for our #clients . We've been able to bring our own vision to life by assembling an extremely talented and capable team and connecting them with our clients toughest challenges.
Over the next few weeks I'll share a few insights and anecdotes from the things we've seen and learned along the way.
If you visited us in the early days, what are your enduring memories? What challenges are you and your teams facing today?
#productdevelopment #productdesign #teamwork #pier38 #startup #consulting #ipo #labzero #softwareengineering #innovation
