I’m sure you know how to play Jenga. Otherwise, let me tell you how easy the game is. First you have to pull one block from the Jenga tower, then you have to put the selected block at the top of it taking care about a possible destruction. Each player has to repeat these steps until the tower has fallen.

In life (like this kind of games), sometimes the easy things come with interesting problems. Sometimes you can be that Jenga tower destructor even on your first game play.

Sadly, we have similar experiences in software development projects. It’s not a secret that you can find so much information about “how to program in 7 hours” –or maybe less time–, also you can download hundreds source code examples from different sites and –if you wish– you can copy and paste pieces of code from GitHub or StackOverflow for fix a problem in your project. Sometimes this programming-way works until you need to improve the code or add new features. And guys, obviously you have to modify the code… and here comes the boom.

If you are a non-experienced-developer is possible that you had some rookie mistakes in your developer history. Let’s take a break here, nobody is judging you, it’s normal, we were almost the same person at the beginning of our developer life and let’s face it… we were n00b developers, so we made a lot of mistakes (and who cares now?)

Symptoms

Ok… being said that, we need to understand the main cause about these problems, otherwise we’ll doomed to repeat this horrible life and the terrible consequences. That’s why we need to talk about symptoms:

1. Please don’t touch it! You don’t want to change anything in the code because every change comes with a lot of fixes. Maybe you don’t remember when your last “clean” deployment was. I mean, your last deployment without any last-minute-fixes
   
2. We don’t need documentation, if you need to add new features you’ll need to review “the code documentation” and sometimes you only have code comments with the highly risk to be outdated.
   
3. We’ll need more time, doesn’t matter if your system is monolithic or well distributed. You’ll have problems if your team needs time for make simple changes because “your system is not flexible” or “is not agile🙄“
   
4. The “just in case” rollback Ok, maybe you’ll need more time for check how to deal with a possible crash system. That’s why you’ll need to define a rollback plan. Awful, isn’t it?
   
5. What about automation testing? There’s no easy way to improve the code without a lot of manual test and –obviously– cross your fingers.
   
6. We “have a guy”, yes, we need a “guy” for modify some “special part of the system”. Sometimes this person-dependency becomes in a big problem even if the specialist is good a team player (something is not working here, you have a good player but what about the sharing the knowledge?)
   
7. Our code is good but… You don’t know how to confirm if all the code is being used in the system. Maybe you have dead code and you don’t know how much of this useless code we have.
   
8. We need to talk (about your source control) Maybe you are using Git but you don’t have any source control strategy, maybe you’ve compressed one folder, named it with something like 20190703-the-very-final-version.zip and saved a copy in your email (and one more time… cross your fingers)

Don’t feel bad if you have all these “issues”, please feel worse if you are aware about it and you aren’t doing anything to fix your Jenga tower.

I have to say each aspect (or Jenga block if you wish) is very relevant and there’s no easy solution or step-by-step methodology, but if you ask me where to begin, there’s no magic here, you need to take a snapshot from the system and look it from different perspectives, maybe you’ll have to define some metrics with a third tool, maybe a third eye could be helpful.

Please don’t forget that sometimes we saw our system –with this Jenga Architecture– like our own child, and remember… there’s no ugly baby… so, we have to work.

Stage 1

But how to fix it? Here’s a short –and open to be modified– checklist:

1. Try to turn the “special guy” in a “team player”, I always hope every specialist want to see more development topics –and maybe other systems– but maybe they can’t do it because they’re kind of hooked with the same tasks in the same system. You can change it and you’ll need to begin with shadow processes and technical talks about the most common issues in the system. Sadly, you’ll find situations when the “special guy” doesn’t like the change… so, you’ll need to do the next move (if you know what I mean) but I’m sure you’ll discover more team players in this journey. You’ll need them for the rest of the tasks.
   
2. Define your source control strategy, I’m big fan of Git and GitHub but if you like other tools or strategies, please be my guest. The idea is avoiding the zip-versioned-files or the classical old and almost effective email-source-control-way. When to begin? well, maybe as soon as possible is a good –and ugly– answer.
   
3. Identify useless and messy code, How to identify this piece of $*@%$#? Well, maybe you’ll need to use tools like SonarQube to check how well (or not) is your code regarding quality rules. Using these tools, you’ll infer it how much code you have to leave in the way –I mean, remove it as soon as you can– or maybe improve it. Besides this, you’ll learn something else about code coverage and technical debt (you’ll see, everything is related)
   
4. Clean your… code! You have to be wise with all your cleaning steps. My warm-up advice is taking advantage of the old folders that –you know– are useless, then you can continue with the duplicated code. Your confidence will be huge, I’m sure about that.
   
5. Always check your code metrics, like I said (or maybe not) I like SonarQube and I always use the metrics to check the health of my baby monster (you know, the system)
   
6. Implement an automation tool, you always will need a third eye for compile, test and get some metrics about code quality. That’s why you’ll need to trust in someone else… okay, you’ll need to trust in something else. It could be Jenkins or another tool like the Azure Pipelines (actually, I think the Microsoft DevOps guys are doing well)
   
7. Identify the main features, This task has to be checked with the product owner (or business owner, I mean, please, some non IT guy!), you need to confirm how many features has our system. This step is very important because you’ll need to understand all the code related about each identified feature. Remember, it’s not a lonely job, you’ll need help from your team.
   
8. Write unit tests over each main feature Let me be clear, you don’t need write fancy tests. You can begin with the most simplest test for each main method. PLEASE, you don’t need write functional web tests, or use cucumber or anything else. You JUST need begin with happy paths (ok, at least one) in the same programming language that your system is written. If you can write a test for the most internal part of the code, it works too because we need warm up in unit testing!
   
9. Confirm that every unit test is working, Yes, green please!

I need to cut the checklist here because you have a lot of work to do BUT this doesn’t mean that the game has been finished.

Stage 2

Ok, maybe you feel comfortable with your checklist progress, but you know that need to take a bigger step. Well, here’s a new game stage:

1. You need more Jenga players, for this stage you must to confirm if your technical meetings and the shadow process are working. A simple way to check it is how well you feel about the specialist-dependency issue and whether you can make internal changes in your team without affect the development progress.
   
2. Your development team need to be leveled-up, Your technical meetings need to include topics about refactoring or some software design techniques like SOLID or TDD. Here’s a lot of practice –and coding– to do.
   
3. Your team must to be able to write new & cool stuff, the final examination for your –renewed– development team definitely has to include programming about:
   • Improvements over the existing code, based on refactoring techniques or code quality advice
   • New features, because the business never stops.
   • New unit testing code, over the improvements, new features or maybe new test cases over the main features (because we need to improve a lot of things, even the happy paths)

A little note here: Please, the “final examination” should be done in real life, we are not talking about paper tests, your team should to be in the “field” as soon as they can.

Stage 3

Again, there’s a lot of work to do and you might be thinking about how effective could be follow each advice from the stages 1 and 2. I can tell you; you’re making new and strong foundations for the next big thing. Maybe the journey could be boring but I’m sure you’ll get it.

What about the next big thing? Well, you’ll need to think and draw and work about it. Here’s the last one checklist:

1. Draw a serious AS-IS diagram, maybe you don’t have an initial snapshot of your Jenga Tower and please no worries, now your Jenga players will help you to fill any gray –or blank– space of your first accurate architecture diagram.
   • Also, you can use this kind of meetings for create and a need-to-be-fixed list.
   • Yes, you’ll need at least one technical meeting.
2. Write your technical commitments then your technical drivers, why now? Because now you know more about your weakness (and you have evidences, not only hunches) so you can be more accurate about your technical drivers. Yes, there’s a difference, a commitment could be oriented to more particular goal, like any item or group of items of your need-to-be-fixed list, your tech-drivers could be more generalist and if you want, you can think in the future.
   It’s time to write and talk with your team about that, please don’t forget the fab-four “has to be”:
   1. Functional: Easy to use (from the final-user perspective)
   2. Flexible: Easy to understand and modify (from the developer perspective)
   3. Extensible: Easy to connect with other systems or ecosystems (from the developer and system perspective)
   4. Automatable: Easy to follow automation needs like testing, deployment, diagnostics and so on (from the developer perspective)
      
3. Think, discuss and draw your big next thing, yes, we are talking about your TO-BE architecture. This a thinking task and you can use all kind of resources that you have. Please be careful about the time and your desired perfection level. You can dream but you have to follow these rules:
   • Obviously, your big picture design (or state-of-the-art picture) has to be linked with your technical drivers and business vision. Now you are talking about of your biz-tech drivers
   • You don’t need a great system with all the nice and fancy amazon-twitter-netflix technical stuff, you’ll be prepared to begin with little changes like simplifying your data components or new REST service connection patterns. My niece told me once, no one cares if you move backwards or forwards, just move! So, think about it.
   • Your dream definitely has to include a new version of your Jenga Tower, and this doesn’t mean you’ll need a new tower (please don’t)
4. You need to define realistic goals and try to turn your Jenga Tower in part of a serious ecosystem, that’s because your tower (and its new version too) always will need be connected with other systems. That’s why you need a “has to be extensible” tech-driver.
   • Each goal has to be easy to measure, not only in time. You have to include business impact, otherwise… you know.
   • Because you need to move to something bigger, I have to share my preference about the silent system replacement (I mean to the component-by-component process) because often is cheaper than a full replacement. At least you want to pay for it. Of course, now I’m not just talking about money.
5. Always do something about the technical debt and the code coverage. You don’t need to use all your development team’s time. You should think how a small % of time could have a big impact on the software quality numbers (there’s a 80/20 rule that could be useful)
   
6. Do you remember the story about my niece? That’s right, you have to move!

Final credits

There’s a kind of sad song that said “nobody said it was easy“, and you know? I’m thinking in all the work that you have to do, and it not looks sad at all. I think it would be a great job but I also you have to talk with a lot of people, I mean, not only technical guys. So, maybe you’ll have to check your soft skills too!

Of course, this game could be boring, and I like Jenga, but let’s face it, nobody likes living over the edge of the tower, so you have to begin playing as soon as you can. Please don’t forget two things:

1. You’ll need more Jenga players to see the top of the mountain.
2. Jenga is just a game, and as in your childhood you can change the game any time (although after this Jenga experience, I prefer other games, so I’m writing about that)

Ok, I have to finish this long-not-long story and I have to say, like the constant evolution of the systems and ecosystems, I’m improving my skills now, that’s why I’m writing in English. So, if you want to give me feedback about this post or even my English writing, please be my guest!

Kinds,
JD