8 things you should care about when creating brand new applications
Writing appplications form scratch isn’t easy. It’s the moment that you will take a lot of decision that may have a huge impact in the future. The point is:
The choices YOU made will benefit or prejudice the future developers? the customers? the company?
In order to help those who are facing this kind of situation (and even myself) I decided to wrote down 8 things that I consider essential when going throuth a situation like this.
Choose the right stack
Are you working for a company?
If the answer is YES, on 95% of the cases the best choice is the language that the company was built upon to. Tooling, guidelines, commom libraries, experienced developers and other things already exists and others teams, for sure, will have good and bad experiences to share lessons learned with you. Cannonicity has much value.
But ok… I undertand that there are some cases that you will choose a language out of the company stack. Data pipelines? python, ok. Tech stack outdated? Delphi? COBOL? Lisp? ok, discuss with other engineers and propose new technologies.
If the answer is NO, understand you app main goals and then study and choose the language you understand is the best. In the worst senario you will have learnt another way to do thigs you were used to. Take this time to learn.
Use diagrams to share you ideas about architeture and design decisions
Document the architeture and design decision that you made with a brief reason why.
And beleive me, drawing diagrams make your ideas much more clear (even for yourself).
Dont’t couple your domain logics to any 3rd party solution
Sending emails? writing to database? publishing messages? making payments?
All this is about writing and exchanging data, your domain does’t need to know about 3rd part implementation details. Interfaces and dependency injection may help you.
Write tests since day one
No excuses for not writing tests.
Make it easy for anyone to implement tests. (unit, integration or whatever kind of test you think is useful)
Use linter since day one
This will prevent a huge piece of work for future maintainers.
Set guidelines and assure they are beign followed since the begginig. Encourage your team to keep improving the guidelines you have defined.
Don’t document every single detail
This is the moment where things are changing a lot as you and your team understand more about the business and the code you are writing.
This doesn’t mean you should document nothing, for sure you should. But stay tuned on the level of details this documents will have to prevent stale documents.
Schedule meetings from time to time to discuss about the existing documents. And , please, make sure to get rid of stale documents.
Stay very close to domain specialists
It’s very important that you and those who will benefit from your app stay on the same page. You must speak the same language (UbiquitousLanguage)
Have you ever read DDD? If not, maybe now is good moment.
Set a clear development flow
Make it easy to setup local evironment to build and run your application, define pull request template with your team, configure CI/CD pipelines, configure staging environment for testing purposes (staging) and pay attention to the things that prevent your team to be high productive.
Keep dependencies up to date since day one (bonus)
Use some tool like dependabot to let your team warned about outdated dependencies. Please, don't let this become an incident or an urgency. This should be a daily basis activity.
Conclusion
A lot of people knows what consists in writing high quality software, but the obvious must be said (and documented) too.
The "initial commit" is the perfect moment to do this.
For you…
What's is the main point to care when writing applications from scratch?
