Technical debt – when the bank really can’t help you out

Not long ago I had a brief 2hr session with a client who were looking at implementing a collaboration platform (read: SharePoint) to support their massively growing business. The discussion as usual went around platform/product capabilities and as usual the topic slowly venture into requirements and different scenarios that the client wanted the system comply.

Due to the growth of the business, all internal systems had soon been left behind and simply couldn’t cope with the expansions – this is often the case for companies that doesn’t factor IT into their business model. Luckily for the client, most of the OOTB capabilities of the product supported directly what they needed, but a few didn’t. These were for the client seemingly extremely important and a custom solution would most likely be needed.

If you’ve ever spent any time in a meeting with a sales representative, you’ll know that the general consensus is to sell – yeah, go figure. But as a consultant there’s always areas that you really need to be careful of entering into – and this is where you need to have an open and honest discussion about the impact a system can have to a business.

Picking a solution (No, you are not given a choice)

Naturally most companies employ consultants because they know that it’s not their core business. So looking at the reasons to adopting a system (any system), from the business perspective, there’s:

  1. The need to increase productivity, or
    • The need to decrease deficiencies in current system
    • The need to cut cost of productivity
  2. The need to introduce controlled/improved processes
  3. The need to expand, or match a shifting market, or finally
  4. The need improve on system quality

It’s a very broad non-specific and/or descriptive list but covers the various models used by management consultants (including PI-MDD, which from a consulting perspective is my personal favourite – that quite often goes against the grain, especially since I’m predominantly a SharePoint consultant). I’m not going to into the how and why of modelling these things, because I don’t have any formal “Consulting” education (can you even get that?) – but i digress – the needs and context needs to be detailed, which is where many smaller corporations don’t see any value – “We know our business and don’t want to pay YOU to tell us about it” – so they find a budget, which rarely actually has any foundation in either context or need, but a “This is our budget, get it done” perspective. The next step is then to either find a solution provider or a product.

The model here is pretty simple..is cost higher than budget.

Double-click, Next, Next, Next, Finish

Once a solution provider has presented a “choice” which matches the “budget”, the time comes to integrate the solution. A short stint from an onsite specialist and you’re up and running. Some time allocated to “Power training” and the business now has a Best In Breed solution. Exit stage left.

At this stage there’s already conflicting ties between the Need and Context. Initially there’s a drop in productivity because most users are having to learn on the job, perhaps mistakes even occur? orders are lost, tasks are left incomplete – and this is were human ingenuity kicks in and the proactive folks simply circumvent the system till such a time as the system can be “fixed”.

What occurs in this instance is a dramatic drop in ROI – the system is not doing what it’s meant to do and staff are either slipping back and using what they previously used or are making up new processes in order to meet their KPIs or deadlines. After all, business must go on and the outcome is “the system doesn’t work”.

Utopia doesn’t exist

Most platforms seems to have a lifecycle that spans over 5 to 7 years before being replaced/upgrade.image

In the period between introduction and end of life – the utopian fantasy with software is that there’s no cost involved with it. Once it’s bought and installed, everything takes care of itself.

Ok, realistically most have an idea that software does need to grow, so storage, backups and servers are all part of the “natural” life of having a software platform.

The decisions to adapt a platform is far more intricate than that. oh, vendors will sell “support and maintenance agreements” to you at a % price. For that you’ll upgrades/updates, patches and an offshored support email that you can use to contact them if you do need some assistance.

But mostly the vendor relies on partners and/or solution providers to take care of that for them.

It’s here that technical debt comes into play and it’s where vendors or solution providers doesn’t want to go. Yes, I’ve just sold you on the idea that you should by my services or product, at a concise price, why can’t I declare all the costs to you right now?

There’s a natural increase in cost associate with a software platform – it comes in the form of both financial and resource efforts and it could increase the investment figures by up to 20% per annum, of the initial purchase cost, very easily.

Technical debt can be calculated – but it’s very complex so I tend to use an analogy to explain that adopting a platform is much like having kids – there’s an initial phase of excitement, followed by a sense of dread because the project is taking a long time and concluded with the reality that it’s a never ending cost that didn’t just stop when the kids left home.

When decisions matter

It’s always hard to sell a software platform/solution based on a high upfront cost, hence why most don’t do it, whilst there’s a seemingly ignorant belief in the fact that off the shelf packaged software doesn’t carry the debt as well.

Most have heard that a bespoke solution is too risky – hiring some developers to slap a system together and then call it a solution is risky, especially when approached like that.

Can you quantify the exact cost for any system? for most, no – there simply isn’t that much tangible proof to state what that figure is. Like with anything else, there’s a risk involved with the business having to change too frequent, which leads to either an out dated solution or a high cost in retrofitting it to meet the new needs.

Yes of course there’s a banging good approach that’ll be offered when this happens – lets go agile!!! For seemingly unknown reason, companies has now decided that agile is risk free. But it still doesn’t eliminate the technical debt that’s accruing – of course not, since the changes to the system is going to cost money and effort.

In conclusion

The only decision that really matter is an informed decision. Go into the adoption process with both eyes open and on the prize. Be aware of all facets of solution adoption and be realistic. The fact is, if your budget cannot sustain the system it needs in order for the business to prosper, then your business model is wrong.

Stick to your guns – why lifecycle management is important in the enterprise

The concept of Application Lifecycle Management is not a new invention that just popped out last year and hit us in our backsides. It’s a very wide topic with a lot of categories, which includes categories such as:

  • Project Management
  • Change Management
  • Release Management
  • Design, Modelling and Issue Management

Yes, that’s right guys and girls (honestly!!) – Project Management is indeed part of the Application Lifecycle (for real this time!!).

This is spread over an even larger list of methodologies and tools, some fluid/agile and some integrated…

We often hear that IT projects are more likely to run over budget, be delivered late and in a state of looking like a bug-ridden open source project…. statistically that’s quite often the case – so why do we bother when we’re doomed for failure? Well, because when things are done right, it just works.

One of the biggest mistakes I frequently notice on IT projects is the failure to understand that it’s not just the development and project management team which has to adhere to a process. (Yes, i know, those that pay the bills just want things done now…you arguing?…s’ok, there’s the door). IT projects are like a house of cards, the more you add and the more complex the “build” becomes, the more careful you have to be – so that means following that process even if it means you have to get approval before proceeding.

I was once assigned to a project to resolve a few bugs here and there. Nothing major, this was final stage of the project, just a few helpful hours when the cycles where free. The first issue I was assigned wasn’t that complex, but getting to grips with the code base and project layout did take a bit of time. It wasn’t really documented and there was nobody around to give a hand. Anyways, after about 1 1/2 of trying to reproduce the alledged bug, I finally gave up and tracked down the BA who’d lodged the bug to start with. For the first 30secs the BA had to get their head around which particular bug I was referring to – all understandable, the project had run for years.

Then it dawned on the BA which issue i was referring to…the message was…

That issue was fixed 1-2 days before it was assigned to you…

Ok,  naturally I wasn’t entirely impressed, so I chased down the PM that’d assigned the issue to me and got the usual blabber about “being newly assigned onto the project” and “we’re all in this together, please stop strangling me…garggle..ugghh..gasp”.

So the incident at least had a release for my homicidal side..

Why did the Project Manager assign the issue to me in the first place? Well, he’d been running around, trying to get resources stitched together to complete the project and get it out of his hair. Yes, he was a newly assigned PM and the developers on board were largely juniors. Obviously a failure to communicate on one level or another….or….something a bit more sinister?

The steps pretty much showed a full breakdown of the lifecycle.

Test conducted -> Issue Found -> Issue Raised -> Issue Triaged -> Issue Fixed….

And then that’s where things really broke down. No detail was found in TFS that the issue had been fixed. It was still assigned to the PM. Still in active status.

Obviously the PM was never informed that the issue had been fixed..who’s to blame for that? The developer? the tester? the PM?

It’s a very basic example of what can go wrong when the process isn’t followed by everybody involved. That includes developers, testers, project managers, stakeholders etc.

Considering how simple this was, the cost was huge and the ROI so small as to be negligent. Look at that from a project perspective, a drop in the ocean, however if that happened often enough the project would fail (unless we had some seriously generous clients and budgets).

Look at this from an enterprise perspective where cost of delays, additional licensing and hardware, consulting resources et al, then it’s obvious that the lifecycle is paramount. Had a process been in place above (well it was, but it obviously wasn’t followed) the waste of time (and additional cost to the project) could have been avoided.

Shortly after that incident I received an email, asking me to make a small change (just a date calculation, v.simple and quick fix) to another feature. I naturally understood that the work item had been assigned to me so I could see all the details of the change (and ensure nothing had been missed in the email), but alas, it hadn’t. Due to timezone differences I needed to wait for the PM to get back on board for the day, to ensure that the details I’d been given in the email was all encompassing. The work item change had been raised as an issue to be resolved – and lo and behold – it also hadn’t been assigned to me. Great, now due to check-in policies in TFS, I wouldn’t be able to check in before the change to go to the test team. Again, and added piece of delay that ends up costing money in the long run. Of course, I could go and make the change to the code base, wait for the issue to be assigned to me, check in and then move on. But, here’s another idea.

How about I DON’T do the work before the “paperwork” is all sorted?

Yes, I waited patiently for the PM to respond to my email – “S’cuse me, sir..please assign issue xx to me and verify all details…kthxbai” – and then I proceeded.

Did it take a bit of extra time to get this done? Of course it did, but what could the consequences have been had I not gone down that path? Again, wasted time and even possibly impacting code and changing features which wasn’t meant to be changed. Again, more wasted money/time/resources.

This is just a small example of why being very careful to follow a set lifecycle is paramount to IT projects – in the whole scheme of things, this wasn’t something major really – however, the project had already rolled way over budget and deadline, why continue to waste resources when a simple process could have prevented it all.

Why developers should never run a country and what we forget is important when writing code…

I’ve always had a very critical view of politics – always figured its easy to wear those rear-view glasses that gives you a perfect 20-20 hindsight and running a country is easy.

Now I’m a developer (and therefore wholly unsuited to ever run a country) and as we all know, developers are really smart – well…at least everybody else seems to think that what we do is sooooo incredibly difficult to do, so alas, we must be absolute geniuses.

Brain%20SpawnOne way in which we are very good at amplifying that image is when we start to throw “Teh Jargon” around. Everything we say, every sentence, is stockpiling TLA’s and FLA’s, making everything we say sound phenomenally complex.

One other way is also in our code – ah yes, the brains of the universe – what makes the work go ‘round. tick-tock…Here’s where our egos gets a serious dose of “I AM TEH BRAINZ”.

We love complex solutions. We love nudging a colleague and go “suck this up, buddy!” and watch his eyes go blank because he has no clue as to what he’s looking at. There’s something fundamentally satisfying in creating something complex and see it work. simple_test-300x299

However, we often forget some of the things we learnt when we first booted up that PC in class..

I remember my very first programming construction teacher (this guy designed the manufacturing system for Lego in the old days when punch cards were hitting it off) – it took us three months to even start to write code – and man, were we impatient – we wanted to crunch that code NAOW!!!

But at first all we were doing were describing the steps involved with creating a cup of coffee. That took us two weeks to do….????…That’s just crazy, but our teacher wanted to prove a point before moving on with something that we should all have thought about – for real, remember we are the smart ones..we’re taking this course after all.

the-kiss-principle1It’s this principle that we forget all about, the minute we enter into the professional world because we have to make sure that our colleagues at least think we know what we’re doing.

Keep It Simple Stupid

It’s perfectly natural for us (especially males) to strut our stuff when we’ve achieved something and we tend to let our code speak for itself. We just forget that the simple solution is the smarter solution.

If questioned about our solution we’ll also shift the burden of proof to defend our solution – again possibly by throwing “Teh Jargon” around. It’s this exact complexity “need” that makes us completely unsuitable to run a country.

I remember one of the fundamental ways to actually map out a process, be it for a multithreaded complex solution or a simple procedural solution – pen and paper out (what? i’m into computers g’damn!) – and then we map out those processes we “think” we need (knowing them would be ideal of course, but we’re developers damn’it and don’t listen anyways). This process was called Pseudocode/prototyping and made the way for flowcharts and UML diagrams/charts. But how often do you think a developer would count Visio in among his most often used tools?

Right, cause we are “TEH BRAINZ” we don’t need any of that smuck – newbies and juniors need that, right?

Developers has evolved, of course, that goes without saying but look into the 1,000s of online communities out there today and look for threads titled “I want to learn programming, where do i start?” and 99% of the responses are “Check our these tutorials” or “Buy this book, excellent way for newbies to start” – and not knocking those answers because those tutorials and that book are generally some of the best sources of information on the language/platform.

We also tend to argue that writing code is a science – we can quantify and qualify everything mathematically – hence it must be a science.

But the part that’s seriously missing is the analytical part – what describes how our mind works when we’re interpreting a solution to a business problem? Well, it’s definitely not “Framework X is da bomb!!” or “You must follow our company’s code convention”. These facets are important for the business, but how processes are mapped down is the ART form. The form that cannot be explained by running extra performance tests on which iteration type works best for a specific solution.

I’ve always stated that developers are NOT business process analysts – simply because we don’t think similarly. We need analysts for that.

So, not only don’t we create the most simple solution but we seem to forget the most important aspects when writing code as we “mature”….