Don’t start writing code

How this can be possible? Why not to write code when you want to create an application?

If you read the last article “7 mistakes” and you will read the next lines you will find that this is the least important part of developing an application. Why? Here are three main reasons, with clear examples from my experience of screwing up with my first solo applications. Don’t worry, I’m still doing it sometimes because it’s a continuous learning process. You will never be able to create the perfect architecture, the perfect application, (it’s how life goes) but you will be able at least to avoid some basic mistakes.

Reason #1: The battle plan

The first reason not to start writing code immediately is the fact that you need to understand the business part better -, more exactly, what your application will do (e.g. is it a shopping application, a payment service, or a game, etc). Next, you need to think about why do you want to do it? Do you want to learn new technologies or to improve your knowledge, or do you want the world to use it and monetize from it? After you answer these two questions, you need to create a battle plan, rather than to immediately start writing the implementation.

What should the battle plan contain? Take a wild guess. If you said “more questions” you are right. If you thought otherwise, you don’t have to worry, as I will give you some tips and tricks, and some start points.

Even you consider that (for example) you can already start implementing the user onboarding part because on every application you need to create an account, confirm your account, and login, it’s possible to find out later on that this case is not always applicable, or that the situation can be more complex than you expected.

I hope I didn’t bore you yet –, and if that is the case: I apologize and I recommend a good cup of coffee or tea to better digest the rest of this article.

I promised you a few tips and tricks for the battle plan and, as always, I keep my promises.

The first tip will be to better research the technologies you want to use. Even if you worked with it/them you will find out that you never covered all the areas and you never knew the full power that it/they have. Did you think of how you can achieve the best performance or the best security (let’s say) in .NET, or of how you can reuse Angular components or created custom directives to help you with DOM manipulation? Or even better, did you consider how to use virtual tables?.

Maybe you will need to integrate some third parties ( Google Maps, money conversion, Google Books API). Did you consider at the beginning if they will provide the desired results and how they can be integrated? All of this needs to be documented, in case something doesn’t comply, so that you can be able to change it from the beginning, not in the middle of development or when a big deployment it’s coming.

A second tip will be to think about what kind of user you will have: is it an application that allows guests (no account is needed), do you want an admin account or a basic account? Because based on these choices you will need to see how they will interact, what they will be able to see or do, how you can manipulate this on code.

Another tip that I consider optional, based on what you decide at the beginning (only if you want the application to be enabled to others), is to take a survey. Yes, you start with some ideas for the product, yet it is very possible that the people will want other features or even that they want another kind of application entirely. From these surveys, you can extract a good deal of good information and next features.

Let say the third tip is to think about how much money you want to invest because the most expensive part can be the hosting and deployment part (AWS Cloud and Azure are not so cheap) and if you have a small budget you will need to find another provider.

After you will find the answer to these tips you will see that the questions (and answers) will start coming to you, and all of them will help you in having a solid ground as a starting point.

Reason #2: Diagrams

The second reason to not start writing code is to start creating the UML diagrams. They are a big piece of application architecture. They can help you to see how the big picture is taking shape not only ion your mind, but also in front of your eyes.

A very similar metaphor to this step is a human creation. After the baby is attached to the womb, it starts creating its shape. Even if the process takes 9 months, the UML is helping us to speed up the process with a few days. Basically, we start to unify all the above research into a body that will grow with every new feature added. In case you work with other teammates, will help them understand better what it is in your mind, how the application components are working together etc. When you are using diagrams, it doesn’t matter what languages you are using, it’s a neutral template that everyone can understand it.

A small tip here, integrate from the beginning the clean code principles (SOLID, KISS/DRY) and the design patterns that apply in your case, don’t postpone them because it is much harder to start refactoring the code.

Reason #3: Research open-source architecture

A final and important reason to “not write code” is to study other open-source application architecture. It’s impossible to not find ( at least) one similar piece with the product that you want to make. It’s very useful to see how other people think it and you will see that you will find cases that you forgot, ignored, or even didn’t know existed. In case you don’t know what architecture to review, try to chat with a more experienced software engineer to give you some advice or suggest a software architecture that can help you spot with less difficulty the problem areas in your application.

The reason of the author

Hmm… After I re-read these few thoughts, I realized I didn’t say too much about my experience and how I realized that these 3 important reasons exist. At least for my first application, I was very eager to start immediately to write code and to see how my hand and brain can build a new application from scratch (it was an application created for learning purposes).

For a full month, I wrote lines of code after lines of code in Angular 8 and .Net. After some time I realized that I got stuck and that I couldn’t scale my application anymore, as I had a lot of duplicated code and I did not know what I want to add next.

I never took a break to think further to see what I want to achieve or what I can add next. In the beginning, I was very happy that I was able to create by myself something with the knowledge that I had at that point. Yet when I got stuck I started to talk with different people, I read some articles and soon enough I realized that I didn’t know anything about creating an application. I didn’t know that much about how the technologies that I used could help me create the application or the important tips and tricks for the languages that I used. The frontend part was more complex than I expected and every time that a new component appeared I needed not only to write the code, but also change the tests, and find new data that wasn’t provided by the server, (so changes also on the backend part), like a ping pong game.

Most of these errors could have been prevented with the above steps, yet back then I didn’t know about them. Still, every day is a new day of learning and improving our skills, much like children in school. The improvement became more visible on the next applications that I created, because even, if I wasn’t able to have a spotless battle plan or architecture, every time a new challenge appeared, at least I knew how to overcome it.

But there is sometimes too much of a something, so I will leave you with your coffee or tea to enjoy it, and if I made you curious — stay tuned because new articles will come up. And don’t forget, play every day and don’t be afraid to fail.