I will revisit this topic after NI Week 2017. Share your thoughts on Technical Wealth, Technical Debt and Technical Assets via the comments section.
I was preparing a CLA Summit Europe recap, but I believe these gentlemen did a fine job of recapping the event and it is a good way to plug their blogs:

We also set up a photo gallery at LAVAG with pictures of the event.
I was fortunate I was able to present once again at the CLA Summit, this time in Vienna. My presentation was about Technical Wealth vs Technical Debt. I tried something new this year to get everyone’s participation, and as you can see on Steve Watts’ photo, I succeeded. Even though the presentation came right after lunch, people were involved in the discussion and nobody took a siesta during my talk 🙂

tip: pink and green were the options given, blue meant:

Audience participation during “Technical Wealth vs Technical Debt” presentation at CLA Summit Vienna. (photo: Steve Watts)


After the CLA Summit, I had the honor of being invited to give the same presentation at CERN. I tweaked the discussion slightly, given that the audience was different, and everyone participated in that discussion as well.
You probably have heard about Technical Debt, but there is not much out there about Technical Wealth. However, given the discussions during the presentations and afterwards, I realized that I hit a chord that resonated with LabVIEW developers. Sometimes we neglect to dimension the real size of our projects. Imagine if you could actually lay out each wire on your block diagrams out in the real world, or if that wire was a road. The size of some of our projects would be the size of a house, a village and sometimes a big city. We cannot afford to cut corners every step of the way. These houses, villages, cities would come tumbling down.
After the presentation, I was asked where to start. To me, the easiest place is to ensure that you have more tests that test your own code. Unit tests, integration tests, and acceptance tests serve not only to prove the quality of your code, but as a reference to the next developer on what your intent was. That developer could be you. What is immediately apparent today, when you are immersed in the project, might not be so clear when you revisit the project months from now. I used to repeat the phrase “program as if you were programming for psychopath, who knows where you live”. I have changed my tune to “be nice to future you (and others)”. Write clear code, provide unit tests that prove that the code works and also describe the intent of you code.  These unit tests are a small technical asset. If you pay attention to this during the duration of the project, you will have a wealth of resources for you and your peers.
Like I mentioned on my presentation, I am not going to take the credit from coming up with such a wonderful idea.  I got my inspiration from Forget Technical Debt- Here’s How to Build Technical Wealth by Andrea Goulet. When I read that article, I felt that I had found my professional soulmate. Many of the points she made are points that I keep making to my team and customers.
At Delacor, we came up with the following definitions:

  • Technical Debt: Suboptimal design decisions based on extenuating circumstances.
  • Technical Wealth: Collection of technical assets that eliminate or reduce suboptimal design decisions.

We believe that investing time on creating technical assets is worth it, because when we are on the face of technical debt, hopefully, we will take a loan from those assets and use them to avoid accruing more debt.
Examples of technical assets any LabVIEW team can start investing on now are:

  • Project Templates
  • Reusable Libraries
  • Use software quality tools: VI Analyzer custom Tests, Style Guidelines
  • Unit Testing Policy
  • API Testers (for example the DQMH Testers)

Here is the video of my presentation at CLA Summit (thanks to Jeffrey Habets for recording it).

After the presentation, the notes I gathered from the board were:
Technical Debt You Will Stop Accruing

  • No more waiting to test until the end
  • Not testing often enough
  • Postponing the clearance of critical issues [and doing important, but not critical, tasks], because Communication with customer may be slow/difficult or “flow-breaking”

Technical Assets You Will Create

  • Create a toolbox of VIs, libs, and classes for our company’s developers
  • Not really a technical asset but: an efficient and instant communication channel with all stakeholders can prevent debts…
  • Standard Configuration Engine
  • Create Configuration Editor Library
  • Establish a good information infrastructure (effective, not necessarily 100% efficient)

Benefits of focusing on Technical Wealth

  • Increase confidence in code
  • Less stress – less time on boilerplate

What Technical Debt will you stop accruing? What Technical assets will you create? What do you think are the benefits of focusing on technical wealth? Please share your thoughts via the comments.
Happy wiring!
Fab
Related: What we will Delacor present at NI Week 2017?