Bilberrry

05/01/2023

Are you struggling to determine whether your software issues are due to technical debt or just a plain mess? 🧐 In part three of our ongoing series on technical debt, we explore how to differentiate between the two.

One indicator of a mess is when the debt: asset ratio is higher than 1, indicating a toxic asset. This can occur due to acquisition or sunk-cost decision-making. It's important to ask yourself how much it would cost to build the right thing from scratch compared to transforming the existing project.

Another sign of a mess is when the debt isn't explicit, leading to confusion and vagueness around it. Explicitly tracking and managing the debt can help move away from "mess" territory.

Lastly, gauge your discomfort level and determine whether it's truly a mess or just an overreaction. Technical teams may have different thresholds than business units, and it's essential to articulate the issues with the code and their severity.

At our company, we believe in staying candid and direct in discussions and not hiding the truth behind a buzzword. Don't let confusion over technical debt or messes hinder your software development progress.

Check out the full article: https://bilberrry.com/notes/is-it-technical-debt-or-just-a-mess/

04/26/2023

Hey everyone! Did you know that technical debt isn't always a bad thing? In fact, according to Stephanie Ockerman and Simon Reindl in their book Mastering Professional Scrum, taking on some technical debt can be a smart move in certain situations!

can be compared to taking out a mortgage to buy a house - it can be a wise investment. However, taking out a second or third mortgage on the same property might not be such a good idea.

So when should you take on technical debt? Here are a few scenarios:

1️⃣ When you need to fix an actual emergency - just like when your house is on fire, you have to take immediate action to put out the flames.

2️⃣ When you want to build a quick prototype to get feedback - it's a great way to get information quickly, but you'll have to rebuild or heavily refine it later.

3️⃣ When you want to build fast to be first to market - but make sure you have a plan for paying it off later.

4️⃣ When you'll generate more value than you'll incur in debt - this is "prudent and deliberate" debt.

Remember, it's important to pay off your technical debt when you can. Don't let it pile up, and actively make time for it.

Check out the article! Link: https://bilberrry.com/notes/when-to-take-on-technical-debt/
This is part two of our ongoing series on technical debt. Check out part one, The Cost of Technical Debt here: https://bilberrry.com/notes/the-cost-of-technical-debt/

04/24/2023

Have you ever heard of technical debt? It might sound like something you owe to a tech-savvy friend, but it's actually a term coined by engineer Ward Cunningham to describe the long-term consequences of technical decisions made during the development process.

Imagine you're starting a business and need to decide whether to take out a loan to speed things up or to slow down and pay cash as you go. That's the same concept as technical debt. Borrowing can be a smart move, but it's not free. You'll have to pay interest in the form of time, effort, and money down the line.

Just like how financial debt comes in different types, technical debt also comes in 13 categories, according to a group of academics who studied the subject. These categories include architecture debt, build debt, code debt, defect debt, design debt, documentation debt, infrastructure debt, people debt, process debt, requirement debt, service debt, test automation debt, and test debt. It might sound like a lot to keep track of, but it's important to be aware of these categories when making technical decisions.

It's worth noting that technical debt isn't always a sign of incompetence or malice. In fact, some of it can be a wise decision. Martin Fowler's quadrant of technical debt explains this perfectly. The quadrant shows that technical debt can be either prudent or reckless and deliberately or inadvertently incurred. Prudent technical debt might be like taking on a mortgage at a price point you can afford to pay, while reckless technical debt is like swiping a credit card and hoping it won't be declined.

We believe in being transparent and open about technical debt. We encourage our clients to take a thoughtful approach to technical debt – to carefully weigh the pros and cons of taking on debt and to plan for its eventual repayment.

If you're interested in learning more about the cost of technical debt and how to manage it, check out here - https://bilberrry.com/notes/the-cost-of-technical-debt/

04/21/2023

Greetings, fellow tech enthusiasts! Today, we want to share with you an insightful article that tackles one of the age-old questions in software development: how much should a team spend on quality? It's a tricky question, isn't it? On the one hand, you want to deliver the best possible product to your clients, but on the other hand, you know that perfection isn't always feasible and that both poor quality and near-perfection can be quite costly.

In the article we suggest that we use a "quality coverage" line, agreed upon by all stakeholders at the beginning of the project, to determine the threshold of quality that we want to achieve. To help us do this, we recommend using the Cost of Quality (COQ) metric, which is a combination of the costs of poor quality (COPQ) and the costs of good quality (COGQ).

But what do these costs entail, you ask? Well, the COPQ includes both internal and external failure costs, with the latter being more expensive due to their broader and harder-to-quantify impact. On the other hand, the COGQ includes the cost of detecting defects and the cost to prevent defects. By investing in the COGQ, we can reduce the likelihood of encountering defects, which in turn can lead to lower COPQ.

Now, you might be thinking, "This all sounds great, but how do we calculate the cost of poor quality?" And that's a great question. The main point we convey is that it can be difficult to determine the full extent of COPQ, as only a small portion of the costs are typically visible at first. However, by listing out defects and searching for them, these costs can become more apparent.

To drive the point home, the article references real-life cases from companies such as Amazon and Google to emphasize the importance of investing in COGQ. So, if you're interested in learning more about this fascinating topic, head on over to our website and read the full article. Who knows, you might just save your company a ton of money in the long run! https://bilberrry.com/notes/the-cost-of-quality/

04/20/2023

Hey everyone!

We recently had the pleasure of working with David’s Bridal on their new e-commerce platform launch, and we’re excited to share some of our learnings with you.

We know that launching any project can be a bit scary, especially if it's taken years to get there. That's why we want to share our approach to building trust and mitigating risk with you.

We believe that the key to success is sprinting towards small, realistic milestones. Think of it like trying to finish a marathon. You wouldn’t start by running the full distance, right? Instead, you’d set small goals along the way to build your confidence and momentum.

Aligning early and often on business requirements is also crucial. It’s like when you’re building a sandcastle at the beach - you need to make sure you have all the tools and materials you need before you start building, or your castle will crumble.

And last but not least, we think it’s important to shoulder some of the risks with your clients. It's like playing a game of Jenga - if you're the only one pulling out the blocks, the tower is bound to fall. But if you share the load with others, you're much more likely to succeed.

If you're interested in learning more about our experience with David's Bridal and how we made their e-commerce dreams come true, head over to our website to read the full article: https://bilberrry.com/notes/project-rescue/

Thanks for reading, and stay awesome.

10/10/2022

Не зупиняємось 💜

05/27/2022

Don't get used to War! 🗣 Не звикайте до війни❗️
We continue to fight! Everyone is on their own front line!

🤗How to support the people of Ukraine 💜 https://lnkd.in/esb76_5x

05/20/2022

Happy Embroidery Day! 💛💙
On May 19, Ukrainians celebrate Vyshyvanka Day. This is a day when people in Ukraine and abroad wear Ukrainian traditional embroidered shirts or vyshyvankas. Ukrainian traditional embroidered shirt is not just a beautiful garment, but a genetic code of the nation.
This day unites millions of Ukrainians and our friends around the world, and symbolizes the unity of generations and our faith in victory over the enemy!

How to support the people of Ukraine 💜
https://bilberrry.com/notes/how-to-support-the-people-of-ukraine/

05/20/2016

+1

Engineering and design are inextricably linked in product design. Product designers need to understand constraints, and build & iterate alongside engineers.

03/25/2016

User Engagement = Fuel

The Fuel to Build an Enduring, Billion Dollar Business