Don't Apologise!

[swatts]

Hello Lovelies,

If you talked to an aircraft designer and they showed you their design drawings but they apologised that they were a bit of a mess and that the design wasn't very good, how keen would you be to go for a fly?

More often than not the first word I hear when looking at someones block diagram is "sorry"

Whereas we love showing off our code, we kind of buy into the software craftsman view of it. We feel our code is well-crafted and have pride in it.

Quite often this contriteness is misplaced, if the code is working and adding value then it is good software in my opinion. It might not be good for all use cases though and this is when we get the call. Most commonly it might be functionally good, but difficult to maintain or extend.

The difference here is interesting and I actually think there are things to apologise for and things that you don't need to apologise.

Say sorry for these!

• Untidy code - this is just effort, lack of effort=laziness.
• Unfixed code - knowing it's wrong and leaving it, I find this very frustrating.
• Vanity Code - Making it complex to satisfy your ego

Note: all of the above are wilful decisions or omissions.

Don't say sorry for these

• Unfinished code - I don't know what time pressures you're under, it's unlikely I'll be asked to look at finished code.
• Designs that grow (mutate) - Good software should grow and mutate, it means it's being used and refactoring is risky, difficult and expensive. The Software Peter Principle applies here, where the code becomes so complex even the author doesn't understand it.
• Code you did before you knew better.
• The system is brittle and changes cause chaos. Change is a use case and while it's reasonable for us to assume stuff will need changing it's not necessarily a given at the time of project inception.

One reason we never feel the urge to say sorry is that we write code slow to debug fast and that involves effort and attention to detail. Debugging fast means we can make changes fast too, they are related.

I've tried to float the index to articles at the top of the blog, been told by NI that it won't work and this article is the tester. 

Let's see<--Didn't Work

Lots of Love

Steve

[FabiolaDelaCueva]

Hi Steve,

I am one of those who apologizes profusely for my first programs. As you said, I shouldn't do that because I wrote them before I knew better and like I mentioned in Twitter, their redeeming qualities is that those programs ran for years and my customers were happy with them. My customers even came back for more features and eventually let me refactor some of those programs. Other applications are still working and they have not needed maintenance nor new features.

This is an example of me not following my own advice. When a customer calls and asks if we should refactor their code I ask them:

1. Does it run?
2. Does it meet your needs? (not wants, needs)
3. Do you need to add new features?
   • If yes, is it easy for you to add new features?
   • How many and how big are the new features you need to add?
4. Are you dealing with intermittent bugs that you cannot figure out how to fix? 
   • What are the consequences of those bugs?
5. Do you need to share your code and you find you cannot share it because others cannot navigate it?

I helped one time a customer update code that was running in Windows 95. I upgraded it to Windows XP and LabVIEW 2012. The original code was written in LabVIEW 4 or 5, I don't remember. It was based completely on Global variables. The global variables were all written in the same place and only written once. They only wanted to add a new channel. I had helped them with other projects and the customer asked for a quote to refactor the application completely. I could have easily sold him on the refactor, but the reality was the application was working for them, it was reliable. It was so reliable that they had left it running on that old computer and the only reason they went for the upgrade was due to the computer starting to show its age. As much as I hated leaving that code out in the world, the reality was that it just needed one more global and that was it. I charged them for a couple of hours worth of work, added the global, verified that everything else was working as expected and that was it. They have called me for other applications and that old, reliable code is still running. We don't always need to refactor everything to the latest and greatest. Whoever wrote that code does not need to apologize for it, it works! it is reliable! and it is maintainable because I was able to add one more feature without much trouble. 

Thanks again for sharing your random ramblings, I needed to revisit this idea and follow my own advise. If it is working, don't fix it!

[swatts]

Thanks for your input as always Fab,

I think the key to your case study is to do with use case changing. In your professional opinion your clients use case was not to make the system easy to maintain and the return on investment (ROI) was not there to pay for it. It's not an easy decision to leave things like that, but sometimes it's correct.

We find we cannot support poorly designed systems in a fashion we like, and certainly don't want to fill our work rosta up with them. So our ROI does skew towards some refactoring. The thing is that if you are honest and clinical in your evaluation of the system you'll get the work, customers can usually tell if you're taking them for a ride.

Your old projects may well skew your decisions the other way, it's embarrassing to have to refactor your own work! (I imagine, I'm a long way past this)

The skewness of these decisions is interesting.

Here's a few more questions to ask -  Rescue Job (Code Review) - Process Description