Bad Renovations in Software

Recently, while doing some work in my basement, I had to remove a vertical bulkhead.  Actually, I didn’t have to remove but wanted to see what was behind it after staring at it for so many years.

When I opened it up, it was empty, there was nothing of use behind it – no vents, no water lines, no electrical, nothing – just empty space.

Well, not just empty space, it was filled with scraps from when it was first built, leftover pieces of drywall, wood and whatever else could fill in that cavity.

It was Technical Debt in all its physical glory.

Code that we have pushed to the side because no one’s ever going to see it.

Code that’s so bad, we don’t even try to hide what it is, we just add it to the pile.

Code that serves no other purpose, except to make work for the next person that comes along.

How many times have you had to go into a project that was rife with bad code that was pure bad debt that now you had to fix?

Bad Debt, if you think back to the mortgage and housing crisis of 2008 and watch the movie “The Short” you know what Technical Debt truly is, bad code, hidden within even more bad code, hidden within even more bad code that somehow works so we call it great and leave it for later or until it blows up.

Good Leaders know when to take on Debt, they take on the good debt, debt that will help their company and team grow.  And they don’t leave it behind, in the next release, the next beta, three sprints down the line when everyone is happy with the results, they go back and do it right, make it better and fix it so the next person that comes along isn’t saddled with a gargantuan problem that blows their project out of the water.

The Good Leaders fix Technical Debt but working on it.  If it’s going to add two weeks to their delivery timeline, they figure out a way to do it and make it happen.  If the team is overloaded and can’t spare the week involved in testing thereafter, they find a way to coordinate with QA and get it done.

We only have Technical Debt because we let it get there, but we all know the answer to fixing it.

You don’t have to be the one to put your hand up and announce you’re going to tackle it and get it done, you need to be the one to start doing it.

Choosing between the Rewrite or Fix It

It’s easier to rewrite something than to figure out what is going wrong.

It’s easier to start from scratch, ignore the history and do it your way.

It’s easier to ignore, then engage.

The decision to rewrite versus fixing a code problem is always rooted in emotion and not the code.

We Can Do It Better

If it’s someone new to the team, their first instinct when this discussion is being raised is to lean towards rewriting it.

Why?

Because they don’t need to learn the old code, they don’t need to figure out what is breaking and where and most importantly they don’t need to understand what decisions were taken and why.

In short, hubris has reared it’s ugly head, they’ve scoffed and they know – “I Can do it Better”.

However, in most cases they can’t, they think they can, but once they get into the weeds of it all, they’ll start to hit the same roadblocks that you’ve encountered in building it up.

We Can Do It Better is a path based on pride and over-confidence.

The Technology Factor

Software platforms and frameworks are being updated an increasingly exponential rate. Every day code is changing. What you write today, could be written better 4 – 6 months from now.

Will you be rewriting your code base every 4 – 6 months to take advantage of these new features?

Doubtful.

If the reason for your rewrite is to “be on the latest framework” or “take advantage of new patterns” that do not result in significant performance improvements with maintenance time staying the same or (hopefully) decreasing, then there is no value on being on the latest and greatest software.

Creating a Make Work Project

Everyone hits a slow period in their daily grind. Some go on longer than others, but it’s there. And when it happens, the first project to come up is code that “needs” to be rewritten and made better.

If this discussion is coming out of left field with no pre-dating factors associated to it, then you are now part of a “Make Work” project and you do not want to be part of a “Make Work” projects. As the name implies, someone has decided that this is a good idea (but it’s not) and as such they are trying to make work happen in order to look busy.

Make work projects never work, they are never completed, they are never good enough and if you suspect one is happening, you should dump it and focus on finding a Do Work project. Do Work Projects matter, they are needed and are value driven.

There are valid examples of when a code base needs to be written, but this number is much smaller than you think (and the success rate even smaller). If you’re being faced with a decision to rewrite versus fix, take a hard look at the decisions and reasons being used to justify the rewrite – are they emotion based or are they based on delivery and technology patterns.

Moving to the Cloud? That’s a solid reason for a rewrite.

Platform being discontinued? It’s a no-brainer, rewrite it.

Trying to fix a few bugs that are “tricky”?

Take a second look, fixing those 5 bugs will have a much greater ROI (Return on Investment) than rewriting your app.

And if you’re looking for the leadership take on this, apply the above logic to your team – is it better to blow up the team and start from scratch or fix the problem and move on?

Unified Service Desk Outside the Contact Centre

The Unified Service Desk for Dynamics 365 should really drop the Service from it’s name and become the Unified Desk.

With the last few incarnations of the Unified Service Desk, the underlying configuration and Framework have grown into an application that can no longer be discounted as a contact centre only client.

Unified Your Applications

How many times have you been using that home-grown system that manages your back-office orders while being transferred a call from the contact centre to look at a customer’s billing statement?

Wouldn’t it be great to not have to change that home-grown application, open the customer case that has already been started and have it send data to your application with no changes to the original application?

Wouldn’t your customers think it’s great when they don’t have to repeat their information to another person for the second or third time?

Or what about being able to setup multiple agent configurations across a multi-tenanted contact centre that allowed you to use the same Dynamics 365 tenant, same security roll-ups and same user profiles but with different configuration profiles, enabling your development team to focus on building solutions and not synchronizing data between multiple tenants.

Simplified Deployment

Or how often do you come in the morning and fire up all three or four applications you need to log into separately, logging into each one and instead simply double click one app, have it load and sign you into all the others?

The argument for having to roll-out a client application is weak at best (the one I hear the most).

With the improvements in downloading customization files to an agent’s desktop, files are streamed to their LOCAL DATA folder (away from the main installation) and loaded on demand (or unloaded after they have been used). Create a configuration file, add it – along with your other files – to a zip archive, add it to the USD configuration and wait for it to deploy.

Custom User Interface

Not sure about how the Unified Service Desk looks?

Create your own – that’s right, create your own.

With the Unified Service Desk you can create your own view with a basic understanding of WPF that aligns to what you want your view to look like so if the traditional 4 panel display doesn’t work for you, create something that models your organization view, complete with branding and deploy it as easily as you would any other Unified Service Desk customization.

Deliver your Dynamics365 Platform

The Unified Service Desk interacts with any customization you have in your solution framework. When implemented correctly, it can be the gateway to your users accessing not only your service centre but all of your applications within your Dynamics framework.

If you haven’t used the Unified Service Desk before or want to learn more about it can do for your Contact Centre or Business, give us a call and we’ll show you how.

 

 

Dynamics CRM Training Courses

BetaRover specializes in the delivery of Dynamics 365 workshops focussed around the adoption of advanced skill sets and learning within your organizations. 

Whether it’s your entire company or a mixed class, our training workshops start with the same approach and philosophy to learning – Understanding what skills you want to learn and what problems you are looking to solve.

(more…)

Digital Transformation Goes Beyond the Move

I’ve seen many strategies over the last year refer to Digital Transformation strategies as moving to a new platform, getting our “stuff” onto a new platform, figuring out what to do when we move it there, taking what we have and putting it there.

As a learning strategy, while in Development, this kind of strategy provides value to your development teams if they are in entering into learning mode with the goal towards figuring out how best to leverage the infrastructure and identify gaps between your current system and the new one you are moving to.

(more…)

Subscribe to Roving Thoughts

Enter your email address to subscribe to this blog and receive notifications of new posts by email.