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.

Finding your Non-Leadership Style

Leadership Styles are a tricky conversation primarily because no one wants to be pigeonholed being “that” type of Leader (when no one cares for having “that” type of Leader in their organization).

But it gets worse, as you start to work with other leaders (maybe you have a group of Team Leads you are mentoring) they want to understand what style you teach and employ because this is more important than the results you create.

To be a Great Leader, you don’t need to have a Leadership style. 

If you want to be better then having a particular style, I would urge you instead to focus on having a Non-Leadership style which essentially says – who you aren’t.

Having a Non-Leadership Style is what keeps you open to changes in the industry and lets you build your toolbox with a variety of tools, adding new ones, replacing old ones.  It prevents the conversation from with team members from going down a path of – “oh okay, so today we’re doing this?”

When you have a Non-Leadership Style you KNOW who you DON’T want to be, what you DON’T want to do and what you DON’T want to teach others.

You won’t find Non-Leadership Styles in a powerpoint deck because there are too many and only you can be the judge for what works for you and what doesn’t from your experience at trying them.

Non-Leadership Styles are typically unstructured and not driven by processes or perfect diagrams.  Instead they are composed of guiding concepts and goals that hold the leader to their path and direction but let them choose the route to get there.

Non-Leadership Styles are not for everyone – there is no handbook (except the one written by the leader) that says – “when this, do that, then do this, followed by that” which can frustrate those that are looking for a step-by-step manual to leadership.  They are free-flowing, evolving and natural in their development, growth, and escalation as they are implemented, tweaked and twisted.  They are the leadership styles that we come to admire for these exact qualities of flexibility and growth.

The next time you get asked what’s your Leadership Style, flip the conversation and start by saying what your Leadership style isn’t.  In that instant, the conversation will change as people here what you will not do and when you start doing what you set out to do they will not be fearful for what comes but instead be relaxed in knowing what it will not be.

 

Conference Season is Upon Us

We’re in the thick of it now – Conference aka “Drinking from the Firehose” Season is upon us.

From now until October, the conversation around the water cooler and SLACK channel’s are going to be focused on one thing.

What conference are you going to this year?

And if you didn’t get your first pick or your choice was assigned to you – the follow-up questions might include…

Where is it?

Is there anything to do there?

Who are you going with?

I don’t have anything against Conferences, as a means to disseminate large amounts of information to a group of individuals they are great.  They are the firehoses of communication to get an idea out to as many people as possible and try to do it in an intimate way as possible.

They are meant to get you excited about doing work when you leave the conference, when you come back to the office with this new found information and want to try something new, change the world, put a dent it, etc, etc.

But.

How many times have you done that?

How many times have you watched all the sessions you missed?

How many times have you implemented what you saw in a conference into a shipping product for release in the next few months?

With the above questions in mind, if Conferences are your primary source of training and you’re not implementing what you have learned into your work in the next 2 – 3 weeks from when you’ve returned from the conference then what value has it brought to your growth.

(I emphasize growth and learning here because I know conference trips serve other values such as team bonding and enjoyment).

If you were to take the funds to be used on you attending that conference what would you do differently to ensure you apply them to your growth path?

Buy twenty Udemy courses?

Register for a year-long Plural Sight subscription.

Sign up for a developer cloud account with all the cool features on it (not only the three ones).

Integrate that decaying “customer required” app into your main code base and get a feel for what it truly does?

The options are endless, I’m sure with half the funds available to you, you invariably take a different approach to your learning.

Conferences are about mass consumption where the other niche training options above are about learning.

Am I looking for Training or Mass Consumption?

What you hope to get out of each is vastly different and applying one goal (I want to learn) to the wrong implementation (firehose) will leave you feeling discouraged in the end.

Know what you want, ignore the hype and figure out the path you need to take to get there and make it happen.

But know that you have the power to make the right choice for your growth.

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.

 

 

Subscribe to Roving Thoughts

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