Today I felt the need to write down some ‘principles’ based on my experiences in software development of the last years. It’s by no means a full list, so I’ll try to update this post regularly when progressive insight pops up. I separated 3 categories: Coding, requirement gathering and agile methodology.
Code is read more often than it is written. Therefor, write only readable code. Readable code is not code that demonstrates how smart you are but code written with the genuine intention to be understood by others. Talk with other team members about code readability and enjoy the effect.
Semantics is everything
Even if you are not a Domain Driven Design practitioner, contemplating about using an ubiquitous language, make sure your code expresses correctly its intention. There is nothing wrong with a refactoring cycle purely devoted to fine tuning the code semantics and making code simpler.
What’s the best code ever?
The best code is the code not written because that’s the only code which is 100% bug free. So, talk with the client/business about complex features with low added value. KISS (keep it simple and stupid) starts already during the requirement gathering phase. Customers will appreciate that you think together with them in “Pareto terms (80⁄20 rule)”.
Learn test driven development
Apply always Test Driven development even for simple features. It will lead to better code composition and provides a generous safety net for incremental refactoring and future changes.
Learn functional programming
Patterns or not?
There is nothing wrong with going through the classic software patterns (style Gang of four) but in the end the S.O.L.I.D. principles really matter. Favor Composition over inheritance. Ensure low coupling but without dogmatism.
Requirement gathering/interaction with business client
release early prototypes
Clients/business parties who are kept too long in a insecure state about the software under development tend to formulate more complex requirements. Therefor early and even premature prototypes are key. Prefer working prototypes over wireframes because the abiltity to inject live data in a prototype makes clients more expressive in formulating requirements as simple as possible but no simpler.
If you think that tools like UML can help you in the communication process with the client and between your team members, use it but often it’s better to stick to simple user stories and some enlightening diagrams which generally don’t fit in what general requirement gathering tools offer. The best communication is the one that is tailored for the specific background and needs of the customer. Creativity, fantasy and imagination are key here.
Favor Living documentation
If you have the occasion don’t hesitate to adopt some techniques that lead to living documentation e.g. Behavior driven development and https://openapis.org/
scrum is a learning experience
Only join an Agile/Scrum team if everyone understands the rules of the game. Avoid teams where management adopted scrum because a ‘sprint’ sounds faster. Join teams where agile is a joint and pleasant learning experience for both developers and business.
apply scrum like a monk
Although they work very hard, monks in a monastery usually experience low stress. That’s because they have a very strict and repetitive daily rhythm. Agile/Scrum is offering the same type of cadence under the form of the daily stand-up and open communication based on trust. Embrace this opportunity to reduce stress.