Lessons from the World Cup: It's All About Planning and Execution
Lessons from the World Cup: It's All About Planning and Execution
What does the World Cup have in common with software development? According to this company founder and Argentina fan, it comes down to planning and execution.
Join the DZone community and get the full member experience.Join For Free
RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.
We, the diehard football fans of Argentina, are not scratching our heads. Probably the outsiders are wondering, how did it end so soon for Argentina? We have one of the outstanding players of this generation and players that are also stars in the most competitive leagues of Europe.
There are many lessons to be learned about the failures of many of the top teams in the World Cup and if we understand the root, we can even shed light on how to build a successful software project in the process.
It all boils down to what Benjamin Franklin said: "If you are failing to plan, you are planning to fail." Most projects fail not because of the technology, but because of lack of planning and execution.
The case of Argentinian team was the paramount example of failing to plan. Our trainer openly said in his book:
"I do not plan anything. Everything comes out when it has to arise. It flows naturally at the proper moment. I hate planning. If I plan, I put myself in the place of an administrative clerk."
His strategy was to put the best components in the industry together and to flip the switch. He failed to plan, and we all saw what happened. I bet you have seen something like this in at least a few projects you have been involved in your career.
On the other side, we have the Germans who are notorious for their planning. They meticulously put all the right components together, but somehow, when they flipped the switch, nothing happened. They failed to execute.
My job before founding Corvalius was to step in at the very last moment to fix projects manned by folks up to their necks in chaos. Ninety-nine percent of the time, the problem wasn’t the technology.
As an example, I witnessed a major telecom company who had a top-notch development team. They knew it, and they planned a super-tight schedule to get their project launched on time while employing the best technology money could buy. As time went by, things started to fall apart. They had to work on Saturdays and Sundays to keep the schedule. For six months nobody got a break. Everybody coded their hearts out, and management was highly supportive. The project was still running behind, and it hardly worked.
I was asked to help with their scalability issues. The problem was that time was running out, and they desperately needed a late goal to get the extra time. Therefore, everybody wanted to score. They forgot that instead of taking a shot with a 10 percent chance of landing in the net, it’s better to use the play they should have practiced hundreds of time during planning and preparation, and pass it to the teammate who has a 60 percent chance of getting it past the goalkeeper.
Whenever a developer touched code, they broke more than they fixed. In the end, they all had to agree not to touch anything as I wrote the final code. Six years later that code was still there, and nobody dares touch it. The truth is, that code wouldn’t have to exist at all if proper and realistic planning would have been done in the first place.
So, how do you approach planning? When working on projects, there are at least two very common scenarios:
You create a new project from scratch.
You create a new version of an already-existing product.
For the former, what you need is to have something that gets the job done yesterday. In many cases, this project will be the first revenue source or the first experiment to know if the project will work at all. You need to get ready as quickly as possible with as few pauses for error as humanly possible. This requires planning, and speed.
The second scenario is much like a team in the Champions League. The team consists of a group of players that accumulate enough playing time together to be able to work as a cohesive unit year over year. But every season there are trades. Players retire. Some get cut. It never changes the entire face of the team, but everyone must adapt to something new. This is what happens when you make a new version of your product.
You need to plan the change. You need to tweak your strategy. You need to coach every member of the team: development, management, users — even marketing and sales. And they must be flexible enough to execute properly.
Because I work with databases, the time has come to talk a bit about execution. For the former, it is generally a good idea to approach it in the NoSQL domain. But probably not for the reasons everybody would think of.
When you are creating a project from scratch, your opponent is the unknown — or what you don’t know yet. Approaching the problem using "schema-less" data design allows your team and your users to reveal their strategy in using your application and adapt fast. If something isn’t working, you don’t have to wait until halftime to change tactics. You can call out new instructions right onto the field and be done with it.
That doesn’t mean you shouldn’t do proper software engineering. It means you should use the engineering tools that better adapt to solve the unknowns. User experience research is a must in the planning and execution stage, proper prototyping methodologies, etc. The "schema-less" nature of most NoSQL solutions is just another tool you can plan to use if necessary.
On the latter scenario, the unknowns do still exist but you have been accumulating knowledge about the behavior of the business and the technology for some time.
As a user of RavenDB since pre-1.0, it came as a surprise to me that they supported binary compatibility for all versions from 1.0 to 3.5. It was working great, making it easy to migrate data from one version to the next. You could take a v1.0 database and upgrade it in place to 3.5 just switching binaries. That’s 8 years’ worth of changes.
When it was announced that RavenDB 4.0 would drop binary compatibility, it was a huge bet, but from the planning point of view, it made sense. The knowns now far outweigh the unknowns. If the execution was right, it was poised to be a huge leap forward. That’s a chance in strategy knowing that the game was going to be different, what remained to be seen was the execution; and it worked and brought with it huge benefits in performance.
In Argentina, we will be watching how the players change, the strategy changes, the trainer changes, and how a real plan for victory develops. Once that happens, we will be excited to see our best get another shot at the 2022 World Cup. To complete software projects successfully, just plan and execute diligently. You don’t have to wait until Qatar.
Opinions expressed by DZone contributors are their own.