There Is Nothing More Permanent Than a Temporary Fix

I can't tell you how many times over the years I've heard some version of this: "Let's just do this for now, and we'll come back and clean it up later."

I've probably said it myself more times than I'd care to admit. And sometimes that's exactly the right decision. You're trying to get a release out, a customer has a legitimate problem, production is down, or there's a deadline that simply can't move.

The business needs something now, and the perfect solution might take three weeks when a perfectly acceptable solution can be done in three days. So you make the practical decision. You fix it, ship it, and move on.

Then something funny happens.

Nobody comes back.

The Problem Isn't Taking Shortcuts

I don't believe technical shortcuts are automatically bad. I've spent too many years working in technology to believe everything can always be designed perfectly from the beginning.

Sometimes you simply don't know enough yet. Sometimes the business can't wait. Sometimes you have to make a reasonable tradeoff between what you'd like to build and what you can realistically build today.

That's business. The problem isn't the shortcut. The problem is forgetting that you took one.

Six months later, the temporary solution is still there. A year later, somebody builds something else on top of it. Two years later, the developer who originally created it has moved on.

Now a new developer finds it and asks the obvious question: "Why does this work this way?"

And nobody really knows.

The temporary fix has become architecture.

"We'll Come Back to It" Needs a Date

This is where I think organizations can do better. If we're knowingly making a compromise, there should be some recognition that we're borrowing against the future.

Maybe we put it into the backlog. Maybe we document why the decision was made. Maybe we identify what the better long-term solution should look like.

It doesn't need to become a 40-page technical document. Sometimes a few sentences are enough: Here's what we did. Here's why we did it. Here's what we should eventually change.

That little bit of context can be incredibly valuable two years later when someone is staring at the code wondering what the heck we were thinking. Without it, the next person has to reverse-engineer not only the software, but also the decision behind it.

Success Can Actually Make This Worse

This is one of the strange things about successful products. If the temporary solution works, there's less pressure to replace it.

The customer is happy. Production is stable. The next opportunity arrives. Engineering moves on.

Why spend two weeks improving something that's working when Sales has a new customer waiting for a feature? That's a perfectly reasonable question.

But ask it enough times, and eventually the platform becomes a collection of things that were all supposed to be cleaned up later.

That's when technical debt stops being a few isolated compromises and starts becoming the way the organization operates.

Then the Firefighting Starts

Eventually those old decisions begin interacting with one another. Changing one thing unexpectedly affects another. Developers become cautious about certain areas of the application. Testing takes longer because there are more scenarios nobody wants to accidentally break.

Then something fails in production. Everyone jumps on a call. The team investigates. Somebody finds the problem and patches it.

Great. Crisis over.

But here's the question I think we need to ask more often:

Did we fix the problem, or did we create another temporary fix?

There's a big difference. If every production issue results in another patch layered on top of the previous patch, we're not really reducing technical debt.

We're refinancing it.

The Backlog Can Become a Graveyard

Most technology organizations have a backlog filled with good intentions. Refactor this. Improve that. Replace this old process. Add automated testing here. Clean up that integration.

Everyone agrees the work should happen. It just never becomes more important than the next customer request, production issue, deadline, or revenue opportunity.

Eventually the backlog becomes less of a plan and more of a historical record of things everyone agreed were important but nobody ever prioritized.

That's not really an Engineering problem. It's a leadership problem.

If we tell Engineering to address technical debt but allocate 100% of their time to everything else, we've already made the decision for them.

Some Debt Is Worth Carrying

I also don't think every shortcut needs to be revisited. Sometimes the temporary solution turns out to be perfectly adequate.

If it's stable, understandable, secure, supportable, and isn't preventing the platform from moving forward, maybe there are better places to spend the time.

That's another lesson experience teaches you. Not every ugly piece of code needs to be beautiful. Not every old component needs to be modernized. And not every technical debt item deserves to be paid off.

The trick is knowing the difference between debt that's harmless and debt that's quietly accumulating interest.

Leave Breadcrumbs for the Next Person

If I could change one thing about how organizations handle these decisions, it would probably be this: leave breadcrumbs.

Document why. Create the ticket. Write the comment. Explain the tradeoff. And if something really is temporary, give somebody ownership of deciding when it stops being temporary.

Because two years from now, the person trying to understand that decision might not be you.

I've been that person plenty of times. You stare at something and think, "Who would possibly build it this way?"

Then you dig a little deeper and discover there actually was a pretty good reason. Or worse, you discover the reason was simply: "We were going to come back and fix it later."

Later has a funny way of never showing up.

And that's how temporary fixes become permanent platforms.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

When Your Technology Jokes Need a History Lesson

I had one of those moments recently that reminded me just how long I’ve been working in technology. It wasn’t looking at my resume or counting the years. It was making an old technology joke and realizing that some of the people around me had absolutely no idea what I was talking about.

That happens more often these days.

Mention Y2K and I sometimes get a look that tells me they know what it was, but only as something from history. Those of us who were actually working in technology at the time remember it differently. We remember the meetings, checking applications, databases, BIOS dates and reports, and wondering what was going to happen when the clock rolled over to January 1, 2000.

Then there are the really fun conversations.

Mention COBOL or FORTRAN and see who recognizes them. Drop AS/400 into a conversation and eventually someone will ask, “What’s an AS/400?”

That’s when you realize you’re no longer explaining technology. You’re teaching technology history.

“Okay, kids, gather around. Let me tell you about green screens.”

Before long I’m explaining command-line interfaces, floppy disks and why the Save icon that everyone still clicks today looks like a little square thing that many younger people have probably never actually held in their hands.

Then there was one of my personal favorites: the TURBO button.

Yes, computers actually had a button on the front labeled TURBO.

Think about that for a moment. Someone actually decided the computer needed a physical button that essentially asked, “Would you like your computer to go faster?”

Of course I would!

Push that magical button and maybe the little display on the front went from 100 MHz to 110 MHz.

Ten whole megahertz!

We were flying!

Never mind whether the processor could actually take advantage of it. The number was bigger. The TURBO light was on. Therefore, as far as we were concerned, that computer was moving faster.

It may have been the greatest technological placebo ever invented.

And if you really want to find out who has been around for a while, start talking about dial-up Internet.

I can still hear that modem connecting.

Try explaining to someone today that getting on the Internet meant your computer literally used the telephone line to call another computer. Then explain that if someone in the house picked up the phone, your Internet connection could disappear.

Or tell them about trying to free up conventional memory in DOS. Editing CONFIG.SYS and AUTOEXEC.BAT because the program you wanted to run needed just a little more memory. Moving things around, rebooting the computer and hoping you gained enough precious kilobytes to make it work.

Today we talk about cloud computing, SaaS platforms, APIs, containers, artificial intelligence and systems capable of doing things in seconds that would have sounded like science fiction when many of us started.

And I think that is one of the things I appreciate most about having spent more than 27 years in this industry.

I’ve had a front-row seat.

I remember Y2K. I remember COBOL and FORTRAN. I remember the AS/400. I remember DOS, floppy disks and dial-up. I remember when megabytes sounded impressive.

And yes, I remember the TURBO button.

So when I make one of my old technology jokes at work and someone gives me that confused look, I’ve learned to smile.

Some jokes simply require 27+ years of prerequisite experience.

And for the record, I still believe that TURBO button made the computer faster.

You’ll never convince me otherwise.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Being a Senior Developer Is About More Than Writing Better Code

Being a Senior Developer Is About More Than Writing Better Code

One thing I have learned over the years is that the word "Senior" in Senior Developer shouldn't simply mean someone who has been writing code longer. Experience certainly matters. Technical knowledge matters. Knowing languages, frameworks, databases, APIs, and architecture matters. But I think there is something else that separates a truly senior developer from someone who is simply an experienced programmer.

It is judgment.

A junior developer is often focused on completing the task in front of them. There is nothing wrong with that. We all started there. Here is the requirement. Here is the ticket. Build it, test it, and move it forward.

As developers gain experience, though, I expect the questions to change. Should we be doing this? What else could this change affect? Does something like this already exist elsewhere in the application? What happens to existing customers? What happens to the database? Could this introduce a security problem? How will Support troubleshoot this six months from now? What happens when the next developer has to modify it?

Those questions aren't necessarily written in the ticket, but they can be just as important as the requirements that are.

Senior Developers See Beyond the Ticket

One of the biggest differences I see between junior and senior thinking is the ability to look beyond the immediate assignment. A ticket might say, "Add this field." That sounds simple.

But where does the data come from? Where is it stored? Who can see it? Can it be changed? Should changes be logged? Does it need to appear in reports? Does an API need to expose it? Will another system depend on it later?

Suddenly, "add a field" isn't quite as simple as it sounded.

A senior developer understands that software is interconnected. Changing one thing can have consequences somewhere else, and those consequences aren't always obvious.

Sometimes the Best Developer Is the One Who Slows Things Down

This might sound strange in an industry obsessed with speed, but sometimes the most valuable person in the room is the one who says, "Before we build this, let's make sure we understand the problem."

That isn't resistance. That is experience.

I'd rather spend another hour understanding a requirement than spend the next three weeks fixing something we shouldn't have built that way in the first place. I've said before that we shouldn't automate bad processes. The same principle applies here. Writing code faster doesn't help much if we're solving the wrong problem.

Ownership Matters Too

I also believe seniority comes with ownership. When something breaks in production, the question shouldn't immediately be, "Whose ticket was this?" The better question is, "What happened, how do we fix it, and how do we prevent it from happening again?"

Good senior developers help junior developers understand why something happened instead of simply fixing it for them. They document what they learn. They question patterns that repeatedly create problems. They help improve the process, not just the code.

Most importantly, they understand that their responsibility doesn't necessarily end when the code is merged. The software still has to live in the real world.

AI Makes Judgment Even More Valuable

This becomes particularly interesting as AI continues changing software development. AI can already generate code remarkably quickly, and that capability is only going to improve.

So if writing code becomes easier and faster, what becomes more valuable?

Judgment.

Understanding architecture. Understanding customers. Recognizing risk. Knowing when a solution is becoming unnecessarily complicated. Seeing how today's decision could become tomorrow's technical debt. And sometimes knowing when not to write code.

I don't think AI diminishes the importance of senior developers. I think it makes genuine senior-level thinking even easier to recognize.

Because being senior was never supposed to mean simply being the fastest person at the keyboard.

It means understanding what happens after you press Enter.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Lessons From 27+ Years in Technology - Part 3 of 3

From Building Things to Building Teams

In the first two parts of this series, I talked about going from building houses to becoming a Web Developer and about spending more than 27 years adapting as technology continually changed.

But there's another change that happened along the way.

My definition of what it means to build something changed.

Early in my career, much of my value came from what I could personally do.

Could I write the code?

Could I troubleshoot the problem?

Could I configure the system?

Could I figure out why something wasn't working and fix it?

Those skills mattered, and that experience still matters today.

But somewhere along the journey, I realized my greatest contribution wasn't necessarily going to come from personally doing every technical task.

It was going to come from helping other people succeed at doing them.

That's a very different skill.

If I'm leading developers, I want developers who are better developers than I am.

If I'm working with database professionals, I want people who understand databases more deeply than I do.

I want infrastructure and security people who will challenge my assumptions. I want product people who understand the customer. I want people earlier in their careers bringing new ideas, new technologies, and different ways of thinking to the table.

I don't need to be the smartest person in the room.

I need to help create a room where smart people can succeed together.

That means providing direction without trying to control every decision.

It means asking questions.

It means removing obstacles.

It means recognizing when someone needs help and when they need room to figure something out themselves.

It means allowing people to challenge you.

And sometimes it means letting someone make a mistake, helping them understand what happened, and giving them another opportunity.

This is also where I've learned that product management and people management are very different things.

Product management asks: What should we build? Who are we building it for? What problem are we solving? Why does it matter?

People management asks: Does the team understand where we're going? Do they have what they need to succeed? Are we developing people or simply assigning them work? Are we creating future leaders?

Both matter.

And when you're leading technology organizations, eventually those worlds meet.

Sometimes you're creating a new product.

Sometimes you're fixing one that isn't working.

Sometimes you're modernizing something that has served the business well for years but needs to evolve.

And sometimes you're evaluating something completely new, like AI, and trying to determine where it genuinely belongs.

My job today isn't necessarily to personally write every line of code, configure every server, or know every command.

There are talented people who can do those things far better than I can.

My job is to bring those people together and help point them toward the goal.

When I think back to where this journey started, there's something almost fitting about it.

I started out building houses.

Then I learned how to build technology.

Eventually, I learned how to build products.

And somewhere along the way, I learned that one of the most rewarding things you can build is a successful team.

The tools have certainly changed over 27+ years.

I'm sure they'll change many more times before I'm finished.

That's okay.

I'm still learning.

I'm still adapting.

And I'm still interested in figuring out what we can build next.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Lessons From 27+ Years in Technology - Part 2 of 3

The Technology Changed. The Need to Keep Learning Didn't.

In Part 1, I talked about starting my career as a carpenter building houses in the Washington, D.C. area while going to school and trying to find my way into technology.

Eventually, I got my opportunity as a Web Developer during the dot-com boom and Y2K era.

That was more than 27 years ago.

A lot has changed since then.

I've watched technologies that were once considered cutting-edge become obsolete. I've watched development languages and frameworks come and go. I've watched infrastructure move from physical servers to virtualization and the cloud. I've watched software evolve into SaaS platforms, mobile become part of everyday life, automation change business processes, and now artificial intelligence begin changing how we work again.

Every one of those changes required learning something new.

And I'm still learning today.

I use AI regularly. I'm interested in what it can do, where it can improve productivity, and how it can change the way we develop products and solve business problems.

But experience has also taught me not to confuse new with better.

That's an important distinction.

After enough years in technology, you start recognizing patterns.

I've seen organizations automate bad processes instead of asking whether the process itself should exist.

I've seen teams repeatedly fix symptoms because nobody had the time, authority, or inclination to find the root cause.

I've seen technical shortcuts that saved a few days eventually cost months.

I've seen organizations choose technology first and then try to figure out what business problem it was supposed to solve.

The names of the technologies change, but many of the underlying problems don't.

That's where I believe experience becomes particularly valuable.

Experience doesn't mean walking into a room already knowing the answer.

If anything, experience has taught me to be more comfortable saying, "I don't know. Let's figure it out."

But it has also taught me which questions we should probably ask before we start looking for the answer.

What problem are we actually trying to solve?

Why are we doing this?

Who does it help?

Are we fixing the root cause or another symptom?

Are we making something better, or simply making it newer?

And increasingly today: Are we using AI because it genuinely improves the outcome, or because AI happens to be the technology everyone is talking about?

Those questions aren't anti-technology.

They're exactly the opposite.

Technology is incredibly powerful when we apply it to the right problems.

I've spent more than 27 years watching the tools change, and I expect they'll continue changing faster than ever.

I'm not an expert in every new programming language, platform, framework, or AI tool that appears.

I don't need to pretend that I am.

What I do need to do is remain curious enough to learn, experienced enough to ask questions, and humble enough to surround myself with people who know things I don't.

Because after all these years, one lesson has remained remarkably consistent:

The best technology professionals aren't the people who already know everything. They're the people who never stop learning.

In Part 3, I'll talk about another change that happened along the way.

At some point, my career became less about the things I could personally build and more about the people I could help build them.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Stop Calling Every Old System "Legacy"

There’s a word in technology that I think we use far too casually: legacy. A system has been around for ten years? Legacy. It uses an older programming language? Legacy. The interface looks dated? Definitely legacy. Someone joins the company, sees technology they wouldn’t choose if they were starting today, and suddenly the conversation becomes, “We need to replace this.”

Maybe we do. But I think we need to be careful about confusing old technology with unhealthy technology. They aren't necessarily the same thing.

Old Doesn't Automatically Mean Broken

I've worked around technology long enough to remember plenty of platforms, programming languages, databases, operating systems, and architectural approaches that were once considered modern. Eventually, everything becomes old. That doesn't mean it stops working.

There are systems running businesses today that have been operating successfully for ten, fifteen, twenty years or longer. They process transactions, manage customers, handle complex business rules, integrate with other platforms, and generate revenue every single day. Some of them aren't pretty, and some certainly need modernization, but age alone isn't a business case for replacement.

The question shouldn't be “How old is it?” The question should be “Is it preventing us from going where we need to go?”

Sometimes Old Software Is Old Because It Works

Software that has survived for fifteen years has probably encountered an enormous number of real-world situations. Customers found edge cases. Developers fixed bugs. Business rules changed. Regulations changed. Integrations evolved. Production failures taught the organization lessons.

Multiply that by thousands of changes over many years and something interesting happens. The old system becomes more than source code. It becomes a record of what the business has learned.

The problem is that much of that knowledge may never have made it into formal documentation. It's simply in the software.

The Ugly Code Might Be Trying to Tell You Something

Every experienced developer has opened a piece of code and wondered, “Why on earth did somebody do it this way?” Sometimes the answer really is poor design. But sometimes there was a very good reason.

Maybe a major customer required something unusual. Maybe an external system behaved differently ten years ago. Maybe there was a regulatory requirement. Maybe someone discovered a production edge case at 2:00 in the morning and fixed something that prevented a serious business problem.

Years later, the comment is gone. The developer is gone. The ticket may be gone. The code remains.

That's why I get nervous when someone looks at an established platform and immediately concludes, “This is terrible. Let's rewrite it.” Before removing something we don't understand, perhaps the first question should be: “Why is it here?”

Modern Technology Can Still Produce Bad Software

We sometimes assume that replacing an older platform with modern technology automatically creates a better product. It doesn't.

You can build an unmaintainable system using the newest framework available. You can create poor architecture in the cloud. You can build technical debt with microservices. You can automate a bad process. You can create an elegant new user interface sitting on top of poorly understood business logic.

Modern tools give us tremendous capabilities, but technology doesn't compensate for weak product governance, poor architecture, inadequate testing, unclear ownership, or constantly changing priorities. A new technology stack placed inside an unhealthy development organization will eventually become somebody else's legacy platform.

So What Actually Makes a System “Legacy”?

For me, the more useful definition has very little to do with age. I'd start looking seriously at modernization when the platform is creating measurable constraints on the business.

Maybe the technology is no longer supported. Maybe security risks can no longer be reasonably mitigated. Maybe finding people who understand the technology has become increasingly difficult. Maybe integrations with modern systems are becoming impractical. Maybe the architecture prevents the company from scaling. Maybe development velocity has deteriorated to the point where meaningful product changes take far too long. Maybe operating the platform costs significantly more than a modern alternative would.

Those are business problems. “It's old” isn't.

Modernization Doesn't Have to Mean Replacement

The choice doesn't always have to be “keep everything exactly as it is” or “throw everything away and start over.” There's a lot of territory between those two extremes.

You can replace individual components, refactor high-risk areas, introduce APIs around older functionality, improve automated testing, modernize deployment processes, move appropriate workloads to newer infrastructure, improve monitoring, or gradually separate parts of a tightly coupled application.

In other words, modernize intentionally instead of replacing emotionally.

That approach isn't as exciting as announcing a completely new platform, but it can be dramatically less risky.

The Rewrite Has Its Own Technical Debt

One of the ironies of replacing an established system is that the new platform starts accumulating technical debt almost immediately. Requirements change while you're building it. Customers still need features. Business priorities change. Developers make compromises to hit deadlines.

Meanwhile, you're maintaining the existing platform and building its replacement. Now you have two systems, two sets of problems, and potentially two engineering efforts competing for resources.

This doesn't mean rewrites should never happen. Sometimes they absolutely should. It means the decision needs to be based on business constraints and technical evidence rather than frustration with the age of the existing system.

Respect the Knowledge Before You Replace the Technology

I've spent enough years in technology to appreciate new tools. I've also spent enough years in technology to respect old ones.

Before replacing an established system, understand it. Document it. Identify the business rules buried inside it. Understand the integrations. Find the edge cases. Talk to the people who have supported it. Figure out which problems actually come from the technology and which come from the processes surrounding it.

Then decide what needs to change.

Sometimes modernization means building something new. Sometimes it means replacing part of what already exists. And sometimes the smartest decision is improving the system you already have.

Old Isn't the Enemy

Technology should evolve. Platforms should improve. Organizations should continuously modernize. But modernization should have a purpose.

We shouldn't replace systems simply because they're old any more than we should keep them simply because they've always worked. Both can be emotional decisions.

The better question is: “What is preventing this platform from supporting where the business needs to go next?”

If the answer is the technology, modernize it. If the answer is architecture, address the architecture. If the answer is process, fix the process. If the answer is governance, improve governance.

And if the system is still reliable, supportable, secure, scalable, and capable of evolving, maybe calling it “legacy” says more about our perception of the technology than the actual health of the product.

Old software isn't necessarily technical debt. Sometimes it's simply software that survived.

This follows the principle in your original presentation that mature organizations use incremental modernization and targeted refactoring rather than assuming an aging platform automatically requires wholesale replacement.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/

 

Lessons From 27+ Years in Technology - Part 1 of 3

From Building Houses to Building Technology

I've spent more than 27 years working in technology, and when I look back at where it all started, I'm sometimes amazed at the path that got me here.

My career didn't actually begin in technology. Before I ever wrote code professionally, I was a carpenter building houses in the Washington, D.C. area.

At the same time, I was going to school because I wanted to break into this growing technology industry. I didn't have decades of experience. I didn't have a long list of certifications. I certainly didn't know where the career would eventually take me.

What I had was a willingness to learn, a positive attitude, and the determination to keep pushing forward until someone gave me an opportunity.

Eventually, someone did.

I started working as a Web Developer in the Washington, D.C. area, and it was quite a time to enter the industry. The dot-com boom was underway, businesses were racing to understand this relatively new thing called the Internet, and the world was preparing for Y2K.

Technology was changing incredibly quickly.

Looking back, though, one thing stands out to me about entering the industry during that time.

You weren't necessarily expected to know everything before someone was willing to give you an opportunity.

You needed some skills, of course. But you also needed the ability to learn, the willingness to work, and the persistence to figure things out when you didn't know the answer.

That last part became far more important to my career than I realized at the time.

Technology has a funny way of making today's expertise temporary. Eventually, the language changes. The platform changes. The hardware changes. The methodology changes. Something new comes along and suddenly everyone has something else to learn.

If your entire value is based on knowing a particular technology, eventually that technology is probably going to change.

But knowing how to learn, how to solve problems, and how to keep moving forward when you don't immediately know the answer has a much longer shelf life.

The carpenter who was building houses during the day while trying to find his way into technology couldn't possibly have known what the next 27+ years would bring.

I didn't know that I would eventually work across different industries, technologies, products, and leadership roles. I didn't know how many talented people I would have the opportunity to work with, learn from, mentor, lead, and eventually call friends.

I certainly couldn't have imagined cloud computing, SaaS, modern mobile technology, or artificial intelligence as we know them today.

I was simply trying to get my foot in the door.

Someone eventually opened that door.

The rest was up to me.

More than 27 years later, I think there's still an important lesson in that.

Sometimes potential isn't about everything someone already knows. Sometimes it's about their willingness to learn what they don't.

That willingness helped me move from building houses to building technology.

And as I'll talk about in Part 2, the technology never stopped changing.

Fortunately, neither did my willingness to learn.

Thanks,

 

Michael Cronin

Website: https://www.michaelcronin.info

LinkedIn: https://www.linkedin.com/in/michaeltcronin/details/experience/