Long-term maintainability

Long-term

There are all types of software. There are spike solutions and one-off scripts that are used and abandoned. Some applications have been developed for just a few years.

Typically startups should validate an idea. And in these cases, you can live with ugly code, with no tests. You might not believe me, but when you just validate the idea, it might be good craftsmanship to work exactly like this!Now, some applications should live for 5, 10, 15 years. Applications whole companies and lots of people rely on daily. Applications that can save or hurt human lives, and transact billions, contain extremely sensitive data. In Flexiana, 80% of the time, we are building exactly these systems.

So please, the following points are here for a reason:

There is no dead code
There is no code nobody wants to touch
There is no untested code
Refactoring is always allowed
Testing is always allowed

No dead code

You use Git. Maybe you use Feature Toggles. Maybe you Branch by Abstraction (https://www.martinfowler.com/bliki/BranchByAbstraction.html). When you know that code is commented or nobody is calling it, take steps that will remove this code from your app.

You might just delete it

You might isolate it to a library. In certain situations, you could even open-source this for others.

You might stop importing it and keep the code for further import if you know that you will need the code shortly.

If you don't expect the code to be used anytime soon, don't keep it. A shorter codebase is easier to understand, easier to change, easier to learn for new colleagues, easier to debug, easier to test, and easier to document

No code people fear

If there is a code people are afraid of, it is usually because either it is ugly, it has difficult logic or is uses technology nobody knows.

If it is ugly, refactor it.

If it has difficult logic, refactor it.

If it's using technology that nobody knows, and if the team needs this knowledge, ask around in the general stream.

"If you are afraid of doing it, you should do it more often."

Unknown thinker

No untested code

Well, you in fact can release on Friday afternoon. Have you tested it?

You can make big changes in the code. Have you tested it?

You can go wild and try this crazy idea. Have you tested it?

In Flexiana, you should know the best practices of unit testing, integration testing, e2e testing, database testing, and test engineering. You should pick the best methods to make sure that the code is of expected quality.

"Just this small change, I don't have to test it."

Said the guy shortly before releasing on Friday afternoon.

Refactoring anytime

Just keep the code clean, changeable, understandable, and testable.

Think economically about whether it's worth it. With great power comes big, you know, responsibility.

"In Flexiana, we have never in our history prevented anyone from testing or refactoring. Not a single time!"

Jiri Knesl

Testing anytime

I was a founder of 2 testing startups (performance testing and usability testing) and was teaching testing & QA best practices for years in dozens of companies. I will always support testing. Please, write tests.