[#ALM] Improving the way we work (all the time, even in Easter time)

Hello!

A few days ago, in Peru some crack hosted the DevDays and today while I was reviewing some materials, I found this slide of Ernesto and while I was runnig 11KMs I did a little thinking about it.

How long would it take your organization to deploy a change that involves just one single line of code?

In my line of work, change is a constant. Once I’ve commented on the type of work with elastic equipment, where we are usually 3 people, and we can get bigger up to 20 with a specific objective and then back to 3. This makes the inspection and adjustment a little more complex than usual. However the basis is to give the best and perform a high quality job, this is something that we must never lose.

So with this scenario in mind, I decided to go back a few steps (about 23 according to my graphics) and try to update 1 line of code in a project / demo that is in production since 2013 April and publish it again.

The process was a little tricky and didn’t take me more than 2 hours, and I want to share some highlights about this:

-The code download was trivial, and the compilation had no problems.

-I cannot say the same of the unit Tests, I started to have problems with a few tests. It seems that our kind friends of JSON decided to update since April of the year until now several versions.

-That was solved with and update of a pair of NuGet packages, and this triggered a series of updates that forced me to wrtie some code. With packages like SignalR, and EOF.

-A year ago, I had a discussion with a member of the team which had pigheadedness in use Azure Mobile Services. Luckily I decided to implement the services with WebApi layer and passing the benefits of Azure Mobile Services. I have open a test project that we started to work and I think that in one year can not update anything.

-That was kudos for me, now I get some punishment about a bad decision I made. Last year I think we can use LightSwitch to a perform a few trivial maintenance in a couple of tables. Those trivial maintenance now have more functionality than a calculation of demographic application, and after migrating the same between versions of LightSwitch, we have reached a point of no return where … I leave this here. This is a bad point for me. And I know that at some point I must raise the priority of this PBI and put it in a Sprint to make the app again.

There are a couple of more stories to tell, but the conclusion is that in my case later 2 hours in upgrading a line of stitching a project in production. And this in an app in which nobody works has between 11 and 12 months old. I don’t even think what it would cost “get back to life” code that is measured in years.

Conclusion: Although it is not a current scenario to meet the need for modifications in code of this type, I will challenge this scenario with 3 participants of the team and see the best way to be prepared for this situation. 2 hours isn’t much when is code is familiar for me, however in a “hostile” environment these 2 hours can easily be 2 days or more… Open-mouthed smile