Category: Management

Todays technology is tomorrows technical debt – building your tech radar

Posted on | by ccadmin

or Technical Debt and the Tech Radar: Staying Ahead of Obsolescence

Ward Cunningham originally coined the term “technical debt” in 1992 to describe the nature of software development—specifically, the need to constantly refactor and improve inefficiencies in your code. Constant improvement. However, the technology itself becomes technical debt over time.

Consider the shift from handmade items to automation. Once automation arrived, the manual process became technical debt. As things become more efficient, older technology that once did its job adequately falls behind to newer machines and methods.

The Mainframe Example

Take servers and mainframes. In the 1940s and ’50s, computers like ENIAC filled entire rooms. ENIAC weighed over 30 tons, occupied 1,800 square feet, and consumed 150 kilowatts of power. It required elaborate cooling systems and teams of engineers to maintain. The project cost approximately $487,000—equivalent to about $7 million today.

Now consider the iPhone I’m writing this article on. According to ZME Science, an iPhone has over 100,000 times the processing power of the Apollo Guidance Computer that landed humans on the moon. Adobe’s research shows that a modern iPhone can perform about 5,000 times more calculations than the CRAY-2 supercomputer from 1985—a machine that weighed 5,500 pounds and cost millions of dollars. My iPhone uses a fraction of the power, fits in my pocket, doesn’t need a maintenance team, and cost me around $500.

Those room-sized mainframes became technical debt. Not because they stopped working, but because something dramatically better came along. So how do you prepare for the technical trends that signal what’s next to become obsolete?

What Is Technology, Really?

Before we can talk about technical debt in depth, we need to define what technology actually is.

Many people think technology means devices, microchips, or other tangible things. But in reality, technology is simply a process or an idea—a better way of doing something.

Here’s a simple example: if it takes you 15 minutes to drive to work every day, but you find a shortcut that cuts 5 to 10 minutes off your commute, that shortcut is a technology. You’ve found a more efficient process. Hardware and software are just the codification of these processes, whether it’s a chip that handles digital signal processing or a more efficient route for walking your dog.

The Triangle of Value

The nature of technology connects to what project managers call the Project Management Triangle (also known as the Iron Triangle or Triple Constraint). This concept, attributed to Dr. Martin Barnes in the 1960s, states: you can have three things, but you can only optimize for two at a time.

Those three things are:

  • Cost — How many resources does it take?
  • Quality — How good is the output?
  • Speed — How fast can you produce it?

Every new technology addresses one or more of these factors. Does it produce better quality? Does it make widgets faster? Does it cost less or require fewer resources?

Once you understand this perspective, technical debt becomes clearer. Technical debt is anything that negatively affects one or more parts of the Triangle of Value compared to available alternatives. Your current solution might still work, but if something else delivers better cost, quality, or speed, you’re carrying debt.

I’m Not an Inventor—So What Do I Do?

It’s true that necessity is the mother of invention. But we don’t know what we don’t know. We don’t always have the right mindset or background to invent a solution to a given problem.

However, others have encountered the same problems and asked the same questions. Some of them are inventors. They do come up with solutions, and they release those solutions into the marketplace.

The question becomes: how do I find these solutions? How do I discover the people who’ve solved the problems I’m facing?

This is where a tech radar becomes invaluable.

What Is a Tech Radar?

A tech radar is a framework for tracking upcoming technical trends that affect your industry. The concept was created by ThoughtWorks, a software consultancy that has published their Technology Radar twice a year since 2010. According to ThoughtWorks’ history, Darren Smith came up with the original radar metaphor, and the framework uses four rings—Adopt, Trial, Assess, and Hold—to categorize technologies by their readiness for use.

But the concept isn’t restricted to IT or computer science—it applies to any field. If you work in manufacturing, aluminum casting, or forging, there are emerging technologies that could make your processes more efficient. If you work in healthcare, education, logistics, or finance, the same principle applies. Some trends, like AI and the internet before it, have broad impact and touch nearly every industry because the common denominator across all fields is the manipulation of data.

The tech radar is a way to systematically track what’s emerging, what’s maturing, and what’s fading—so you can invest your time and resources accordingly.

Building Your Own Tech Radar

There’s a layered approach to building a tech radar, as described in Neal Ford’s article “Build Your Own Technology Radar.” You can enhance this process with AI tools. Here’s how to structure it:

Step 1: Identify Your Information Sources

Start by figuring out the leading sources of information for your industry:

  • Trade journals and publications — What do experts in your field read?
  • Newsletters — Many thought leaders and organizations publish regular updates
  • Websites and blogs — Company engineering blogs, industry news sites
  • Professional organizations and memberships — IEEE, ACM, industry-specific groups
  • Conferences — Both the presentations and the hallway conversations
  • Books — Especially those that synthesize emerging trends
  • Podcasts and video channels — Increasingly where practitioners share insights

Step 2: Create a Reading and Research List

Organize your sources into a structured reading list. Here’s a sample format:

Source Type Name Frequency Focus Area Priority
Newsletter Stratechery Weekly Tech business strategy High
Journal MIT Technology Review Monthly Emerging tech High
Blog Company engineering blogs Ongoing Implementation patterns Medium
Podcast Industry-specific show Weekly Practitioner insights Medium
Conference Annual industry conference Yearly Broad trends High
Book Recommended titles Quarterly Deep dives Low

Adjust the priority based on signal-to-noise ratio. Some sources consistently surface valuable trends; others are hit or miss.

Step 3: Structure Your Radar Spreadsheet

The classic tech radar uses four rings to categorize technologies:

  1. Hold — Proceed with caution; this technology has issues or is declining
  2. Assess — Worth exploring to understand how it might affect you
  3. Trial — Worth pursuing in a low-risk project to build experience
  4. Adopt — Proven and recommended for broad use

You can also categorize by quadrant, depending on your field. For software, ThoughtWorks uses:

  • Techniques
  • Platforms
  • Tools
  • Languages & Frameworks

For other industries, you might use:

  • Processes
  • Equipment/Hardware
  • Software/Digital Tools
  • Materials or Methods

Here’s a sample spreadsheet structure:

Technology Quadrant Ring Date Added Last Updated Notes Source
Large Language Models Tools Adopt 2023-01 2024-06 Mainstream for text tasks Multiple
Rust programming Languages Trial 2022-03 2024-01 Memory safety benefits Engineering blogs
Quantum computing Platforms Assess 2021-06 2024-03 Still early, watch progress MIT Tech Review
Legacy framework X Frameworks Hold 2020-01 2023-12 Security concerns, declining support Internal assessment

Step 4: Use AI to Aggregate and Summarize

If you’re monitoring many sources, you can build an aggregating agent that:

  • Pulls in articles from your reading list
  • Identifies recurring themes and emerging trends
  • Flags when multiple sources mention the same technology
  • Summarizes key points so you can triage quickly

Some trends come and go. Others stick around and reshape industries. The goal isn’t to chase every new thing—it’s to assess which trends deserve your attention and investment.

Step 5: Review and Update Regularly

Set a cadence for reviewing your radar:

  • Weekly — Scan your newsletters and feeds, note anything interesting
  • Monthly — Update your radar spreadsheet, move items between rings if needed
  • Quarterly — Step back and look at patterns; what’s accelerating, what’s stalling?
  • Annually — Major review; archive obsolete items, reassess your sources

The Cost of Ignoring the Radar

Here’s a cautionary tale. In the 1970s and ’80s, Digital Equipment Corporation (DEC) was a giant in the minicomputer market. Co-founded by Ken Olsen and Harlan Anderson in 1957, DEC grew to $14 billion in sales and employed an estimated 130,000 people at its peak.

But as MIT Sloan Management Review notes, DEC failed to adapt successfully when the personal computer eroded its minicomputer market. The company’s struggles helped inspire Harvard Business School professor Clayton Christensen to develop his now well-known ideas about disruptive innovation.

Olsen was forced to resign in 1992 after the company went into precipitous decline. Compaq bought DEC in 1998 for $9.6 billion, and Hewlett-Packard later acquired Compaq.

The technology DEC built wasn’t bad. It just became technical debt when something better arrived. They were married to their favorite technology and weren’t ready to change with the times.

Conclusion

Technical debt isn’t just about messy code or shortcuts in a software project. It’s about the broader reality that any technology—any process, any tool, any method—can become debt when something more efficient comes along.

The tech radar is your early warning system. Build one. Maintain it. Use it to make informed decisions about where to invest your learning and your resources.

And remember: don’t be married to your favorite technology or methodology. The next wave of technical debt might be the tool or process you’re relying on right now.

References

Concepts and Definitions

Historical References

People

Computing Power Comparisons

Professional Organizations (for Tech Radar Sources)

  • IEEE (Institute of Electrical and Electronics Engineers): ieee.org
  • ACM (Association for Computing Machinery): acm.org

Further Reading

  • Book: DEC Is Dead, Long Live DEC: The Lasting Legacy of Digital Equipment Corporation by Edgar H. Schein et al. Amazon
  • ThoughtWorks Technology Radar Hits and Misses: ThoughtWorks

Stop Playing Telephone with Your AI: A Structured Approach to Conversational Programming

Posted on | by ccadmin

Have you ever played telephone? A message passes from person to person until it reaches the last player, who compares what they heard to the original. The results are often hilarious, but in a company or organization where coworkers relay messages this way, the results could be costly and disastrous.

When you do conversational programming or vibecoding with an AI agent that writes your code, you’re playing telephone. This becomes especially difficult if you lack programming background, knowledge of language frameworks, or coding principles. Even experienced programmers who use vibecoding end up writing programs they can’t maintain or understand.

However, I believe programmers who have bad experiences with vibecoding are the same ones who don’t use best practices like test-driven development, agile, extreme programming, or DevOps. Organizations struggling with AI adoption are often the same ones struggling with Agile, Scrum, and Lean practices. It comes down to the telephone game — no contracts, no rules, no real structure for communicating safely.

Applying Engineering Discipline to Conversational Programming

In my experience with conversational programming (I prefer that term over vibecoding since that is what your doing, having a conversation with an AI), you must apply engineering discipline when having AI write code. Here are tips I find useful.

Start with a Well-Crafted Prompt

When developing an initial prompt, have a decent LLM write it. I first conceptualize what I want done, but understanding terminology and concepts are important. I recommend Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond by Gene Kim and Steve Yegge. They did studies on companies that successfully implemented vibecoding into their enterprise. What they found is they succeed because they use structured engineering approaches, applying DevOps principles—descendants of Extreme Programming using test-driven development, CI/CD pipelines, and testing tools.

Write a prompt, have an LLM agent refactor it, then record and archive it for future use. This creates a solid one-shot prompt.

Use AI Coding Agents, Not Chat Interfaces

Don’t use ChatGPT or chat-oriented interfaces to do a back and forth with a chat window and your IDE. Use AI coding agents like Windsurf, Cursor, Claude Code, or Cline. I personally use Claude Code with a subscription plan because I burn through many tokens, and Claude by Anthropic doesn’t place strict caps on token usage like API-based agents do.

Learn and Apply Test-Driven Development

Learn test-driven development concepts and include them in your prompts. TDD’s key tenet: write tests first. Know how programs or functions should behave and write tests around that.

TDD forces you to write programs in modular, testable ways. When your AI writes code, it tests for errors and rewrites until it works. For instance, without TDD, my Ionic app became a spaghetti mess—fixing one part broke another because dependencies and regressions weren’t tested. The blast radius of fixes affected other parts, growing to thousands of lines the code editor couldn’t contain.
In my github repo, I have a few applications that I have developed using TDD. I used AI coding agents to write the tests and then test the code against it.

Applying TDD to AI projects made code manageable and adding features easier. Modified modules had to pass tests, so the AI knew what broke and fixed it.

Use Configuration Files to Guide Your Coding Agent

Use various MD files to guide your agent. For instance, with Claude, there’s a CLAUDE.md file tuning agent behavior and an AGENT.md file with application instructions. Write separate MD files for architecture, coding, user interfaces, and so forth.

Leverage MCP (Model Context Protocol) Servers

MCP (Model Context Protocol) servers make AI coding agents more efficient. I spun up a Penpot server (a web-based graphic design tool), created an MCP server connecting to Penpot, had Claude Code connect to it, and using descriptive statements and image captures, Claude designed a website with my preferred color scheme and look. It happened right in front of me.
Here is a youtube video showing taking a napkin sketch and turning it into a web design.

MCP servers can talk to your web browser to help debug websites. Since I’m not a great graphic designer but know what I like, I describe basics, refine descriptions using an LLM, combine this with napkin sketches, and create prototypes I like.

Practical Application: Flutter Development

This approach works for difficult tasks like Flutter development. Flutter is a useful cross-platform framework but a pain to develop—all widgets must be described in Dart, a language specific to developing in Flutter. Using Figma or Penpot designs as references with an AI coding agent, creates widgets that work properly, opening doors to cross platform Android and iOS app development.

You Still Need to Understand the Fundamentals

You still must test applications because AI agents don’t necessarily make correct assumptions about your system or server. You must verify their assumptions match reality.

You still need to know how to code and set up Docker instances. You can ask AI for assistance, but there’s much AI won’t do for you—and that’s OK. It handles heavy lifting and helps with cognitive load.

Working Within Constraints

For those saying AI can’t do everything or write code right out of the box when given difficult problems—you wouldn’t do that with a junior engineer. Work with constraints. As Eli Goldratt explains in The Goal about the Theory of Constraints, you leverage limitations.

LLMs struggle with giant monolithic codebases. However, decomposing problems into smaller, modular chunks allows AI to write complex applications.

Let AI do its thing. AI handles smaller details well, though you must still test the application.

Conclusion: Stop Playing Telephone

You need good communication. As with any relationship, make everything clear and you know where you stand with the person. Establish agreements: how you’ll communicate, what norms exist, how you’ll interact with others in your group, and honor those agreements. The same applies when working with AI.

Rethink how you approach tool limitations and learn to work around constraints. Context windows, resources, and LLM abilities may someday match senior-level programmers. Meanwhile, learn to work with constraints and make communications better and concise.

Stop playing telephone with your AI, start learning how to communicate better with it and give it some guardrails.

References

Books

Tools & Technologies

Concepts

retrospect 2024

Retrospect 2024 – Don’t be the “smartest man in the room”

Posted on | by ccadmin

Retrospect – “a review of or meditation on past events”
A few things come to mind when I reflect on 2024 and think about the past year’s lessons.

1 – Don’t be the “smartest man in the room.”  The phrase “the smartest man in the room” came from Richard Holbrooke, from a 1975 article, meaning the most intelligent person does not guarantee being correct or wise.
Being in the technical profession, we tend to plan, plan and plan.  Look at every angle possible and do all our research all by ourselves.  Then, execute the plan.  Otherwise known as “Waterfall,“.
Whoever comes up with the plan is “the smartest man in the room.”  As implied by the article of the name, it doesn’t go very well for that man with the plan.
The smartest man becomes the bottleneck – since he has the plan, all the eyes look to him for the answers to what isn’t quite clear in the plan.
The smartest man doesn’t know the future – since he has the plan, he makes educated guesses on what the requirements may be.  He’s not Nostradamus, and the guesses are often wrong, which can cause the plan to fail.
The smartest man is under a lot of stress – when the plan starts going sideways, or even if it doesn’t, you can’t ultimately control the outcome.
2 – “Bring it to the team” – In the book “Coaching Agile Teams,” Lyssa Adkins often advises that you bring anything involved with the plan or affects the group to the team.  This is the basic concept of Agile and the Scrum Framework. This is the opposite of being “the smartest man in the room,” which is:
There is no bottleneck with a team – As the team of people is self-managing, everyone is in the loop.  They know what the tasks are, the big picture, with a high degree of trust.
The team doesn’t know the future but can adapt and change – instead of making guesses about everything up front into the future, you plan and make a short time-boxed sprint to minimize the risk of a bad assumption and get feedback from stakeholders to make sure you’re going the right direction with the projects.
The team shares in both the risks and rewards – As a group, you minimize the group and the stress, and also, as a group, you can do more collectively than individually.  Almost everything you use, such as a car, house, bread, and laptop computer, takes a team of people, materials, and time to make.
3 – Practice “personal Agile” – Personal Scrum and other Agile tools can be used for yourself.  I have my own Kanban/Scrum board that I use to keep track of my own projects and tasks.  If you apply the concepts from Agile to yourself, it helps with things like overplanning, procrastination, and being “the smartest man in the room.”  Your “team” is the people in your network who can help you with your projects and fill in your knowledge.

What was an “Aha moment” was the Enterprise Technology Leadership Summit (“The DevOps Summit”) that I attended last year, which put a few of these things into perspective.  While I understood and used the tools and techniques for DevOps/SRE at work, you need Agile to get the most out of DevOps and the Agile mindset in your place of work.

Besides the Agile Manifesto, I recommend reading “Scrum, Do twice the work in half the time” by Jeff Sutherland.  It’s one of the most basic frameworks.

These are what I learned from 2024.

Looking forward to 2025 and maybe something useful you can get from this.

Book Review – Atomic Habits

Posted on | by ccadmin

I look at every day as an opportunity to improve myself not just on new years. If you’re into improving systems (Such as using DevOps) then why not improve the most important system you have…Yourself.

James Clear has written in my opinion a clear and practical way of changing your habits by working on a system of habits in his book Atomic Habits. Instead of having a resolutions such as “I will lose 500 pounds by the end of the year” or “I will make $1,000,000 a year” which are for the most part impossible goals since you don’t have the systems of habits needed to not only reach the goal but to support it in the long run.

Without the system, more than likely even if you reach your goal let’s say losing 50 pounds… without the systems of habits, months after you reached your goal you would have not only regained the 50 pounds you lost, you have gained another 25 pounds on top of that. The same thing that happens with the Lotto winners who won a million dollars, they end up spending it all and being worse off than they were in the beginning.

What are the Systems of Habits? Every system is made of smaller individual components or atomic habits. Instead of doing many individual tasks that require lots of conscious effort, why not build a collection of complementary habits. For instance, suppose you want to write a book, you start with a daily habit of writing 50 words a day in the morning. Writing not when you feel inspired but out of habit.

James Clear gives several examples of building habits that help you obtain long term goals. Marginal incremental gains will result in tremendous long term gains. Each habit has a long term cumulative effect on reaching your goals.

An example he gives is the British cycling team. In over a hundred year s they, only one gold medal in the Olympics in cycling and they never won The Tour de France championship. Enter David Brailsford, a specialist in marginal gains. He started changing little things such as the clothing that the riders would wear for wind resistance. Bicycle seats were more comfortable for the riders. Matresses and pillows were more comfortable to give the cyclist a better night’s sleep. They also changed the type of gels they used for muscle recovery. Painted the inside of the vans white so they can see if there was dust in the vans. Hundreds of small improvements. In less than five years, the British cycling team started winning gold medals. They dominated the cycling event in the Olympics in China. Three of their riders went on to win the coveted Tour de France multiple times (2012, 2013, 215,2016,2017,2018).

The idea is to work on small consistent habits that you learn to do without thinking and effort that complement other habits that help you achieve your long term goals. Those habits don’t stop after you reach your goal, they continue and allow you to achieve the next goals you have. Pushing you forward without much effort. Just getting started is the hard part.

I have already applied these principles to developing a system of habits of my own.

Here are a few examples of things I’ve done to be a better writer:

1 – Review daily a technical stack such as a framework, language, operating system, etc.

2 – Write at least 50 words a day in any form, such as an article, discovery journal, etc.

3 – Exercise every day at least one pushup.

Each one of these habits complements each other towards the goal of being a better writer. Reviewing the nuances of a framework or language helps me to keep my skills sharp on languages or frameworks I don’t use as often. Writing regularly not when I’m inspired or under a deadline keeps me consistent and disciplined in my writing. Exercise helps me keep fit and helps me manage my energy as I write.

I make it convenient to track my habit with a Goal Tracker app on my Android phone. I use an Anki App for my Android device to review things like IOS and Javascript.

What I notice I started to do after a certain point, that the daily checklist activities became automatic. They became habits I didn’t have to think of tracking at some point. All of these habits aid in reaching my long term goals.

I highly recommend this book not only to learn something about yourself but learn HOW to think strategically about developing habits that help you reach your long term goals.

The Triangle of Value

Posted on | by ccadmin

It seems like everyone wants everything these days. They want high quality products and services in the quickest amount of time at the lowest price possible. This is never the case.

I don’t recall people talking about this fundamental concept very often that is The triangle of value. It’s also known by many other names. This is a basic resource constraint when you are offering a product or service.

The triangle of value is this:

You have Time, Cost and Quality – Pick two.

You can have a low cost product very quickly but the quality suffers.

You can have a high quality product relatively quickly but it will be very expensive.

You can have a high quality product at a low cost but it will take lots of time to develop.

This is true of project management and DevOps as well. At the end of the day, these are the three elements you have to work with.

Open source products also work like this. You can have a low cost product (it’s free…so to speak) which is high quality with many features, but it gets done on donated time. It may take some time before a bug is corrected or a new features are added.

Other things that affect the “triangle of value”

Skill and Experience

Skill can reduce the amount of time it takes to make something and it can also affect quality of a product or service. Then again, you will pay more money for an individual with a higher skillset especially if you want to keep them around.

Technology

It can be something that decreases the amount of time you spend on producing a product or service. It can be in the form of automation or another catalytic process. At the end of the day, all advancements of technology are catalysts for getting more stuff out of a process. On the other hand, technology can take time and expertise to develop. This also can cost more money for better tech.

How does this understanding play into DevOps or anywhere else?

In an ideal world, you may be able to hire the brightest minds who are up to the task, have the best equipment, plenty of lead time for getting to market and an unlimited budget…but this is not the case.

It may be more like, you only could hire 2 of the 5 positions for experienced programmers (maybe your one of them) and they aren’t that bright (they just think they are), you have second hand equipment that is a few years old, your budget is a quarter of what you were promised and last week was when you had to get the project done.

That’s ok, these are the reality of the industry. You do with what you can the best you can, the same principles apply.

If you don’t have enough manpower, you make it up with overtime and finding leverage somewhere…maybe automation.

If you don’t have the latest equipment, let’s say it’s slow…you make it up by getting more of the older equipment and use them in parallel using some clever programming and networking.

If you have a short lead time, you loosen your “quality” regiment (as in hope your developers don’t make mistakes writing code by forgoing tests) to save on the time you spend in development.

DevOps CI/CD the “Holy Grail” may be a lofty goal to achieve if your resources are limited, but it is a worthwhile and doable. It may take some time to figure out how to do it and to build and train the resources to do this.

At the end of the day, what you most value is what you will get. You can’t have it all but you can choose what you can live with.

I am open to feedback and any suggestions you may have. Until then, have a good day.