Software Developer Assumptions

2023 04 01 head

Here are some software development topics I have learnt to like after 40 years in the industry.

I worked at quite a few industrial and commercial digital product development initiatives. I truly enjoyed creating successful solutions.

Over the years, I encountered similar architecture and design patterns when creating source code for these applications.

I started programming with languages such as Ada, Portal, and C. I embraced object-oriented languages with first C++ and later Java.

The rise of agile approaches quite increased the fun and motivation in digital product development. The Agile Manifesto and the cited 12 Agile Manifesto Principles still ring as worthy ideas to create better products.

Again and again, our teams had to find ways to learn, tackle complexity, improve cohesion, and master coupling.

Modern engineers create increasingly complex and sophisticated systems. So as well as focusing on learning and modern engineering, we need to focus on managing complexity.

We need to focus our tools, techniques and mindset on dealing with the complexity [1, 2, 3].

Strongly Agree

I strongly agree with these statements:

  • Typed languages are better when you are working on a team of people with various experience levels. The bigger your application, the more helpful is compiler support.

  • Stand-ups are actually useful for keeping an eye on the newbies. They help to detect a team member stuck in a loop.

  • Sprint retrospectives have their place so long as they are for actual improvements. They are the holy shit, well, that went poorly!, and not some awful scrum master driven waste of everyone’s time.

  • Developers should not be isolated or left to just code. Bypassing traditional product managers and agile product owners, they should talk directly to the customer. It always reveals more about the problem, in less time, and with higher accuracy.

  • Software architecture matters probably more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.

  • Java is quite a cool language. Modern Java with streams, modules, pattern matching, or structured concurrency is fun to use.

  • Clever code is not usually good code. Clarity trumps all other concerns.

  • Bad code can be written in any paradigm. Programmers steadily writing bad code should be fired.

  • So-called best practices are contextual and not broadly applicable. Call them good practices. Blindly following them makes you a fool. The agile community recognized the dangers. They only advocate good practices and emphasize the importance of the context in which they are applied.

  • Designing scalable systems when you do not need to make you a bad engineer.

  • Static analysis is actually useful. Scanners like SpotBugs or SonarLint regularly find errors and smells.

  • DRY is about avoiding a specific problem, not an end goal unto itself.

  • In general, RDBMS are better and simpler than NoSql solutions.

  • Functional programming is another tool, not a panacea. The real world has objects and often classes.

Positive Experiences

I learnt to appreciate these approaches:


  • Pencil and paper are the best design and programming tools and vastly underused. Better are whiteboards to exchange ideas in a team.

  • Trading purity in exchange for practicality is usually a good call.

  • Adding more technology in response to a minor problem is rarely a good call.

  • Design is driven from requirements [4]. Building anything beyond those requirements puts you into the world of speculative, self-indulgent invention.

  • 90%, maybe 95%, of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency [5].

  • After performing over 2000 interviews, I can say that standard human resources interviewing is thoroughly broken. Technical interviewing and peer interviewing work way better and are more accurate.

  • Agile approaches are more successful and more fun. Waterfall approaches suck [1].

  • DevOps advantages are worth the effort. Deliver frequently and automate. Each project should have a continuous integration, continuous delivery, and continuous deployment pipeline. The deployment can also be triggered manually. The deployment steps shall still be fully automated.

  • Static websites written in Asciidoc and using site generators such as Hugo are the solution how to document your architecture and technical product [2].

Old Beliefs

I still think these statements should be applied in current teams:

  • A software developer shall have formal training in computer science and software engineering. She should hold at least a bachelor’s degree. A software developer should understand theory such as e.g., CAP theorem and big O notation.

  • A junior Java developer shall pursue a formal Java programmer certification. The learning effect is not always huge, but as a team member, I have security that they know all basic concepts.
    Modern Java supports such concepts as algebraic data types, functional programming, monads, structured concurrency. A professional developer shall apply them in her daily work.

  • People who stress over code style, linting rules, or another minutia are insane weirdos.

  • Code coverage has absolutely nothing to do with code quality.

  • Monoliths are pretty good in most circumstances. The key is to write modular monoliths. [3].

  • Micro-services require justification.


[1] D. Farley, Modern Software Engineering. Pearson Education, Limited, 2022 [Online]. Available:

[2] N. Ford, R. Parsons, and P. Kua, Building Evolutionary Architectures: Automated Software Governance, Second. O’Reilly Media, 2023 [Online]. Available:

[3] R. C. Martin, Clean Architecture. Pearson, 2017 [Online]. Available:

[4] E. Evans, Domain-driven design. Addison-Wesley, 2004 [Online]. Available:

[5] C. Larman, Large-scale scrum. 2017 [Online]. Available:

1. It is time to retire the V-Model, Hermes method, and similar geriatric methodologies. They have served their time. They can rest in peace. The same could be said about SAFe.
2. The huge gain is always current documentation and free versioning of the documentation with the source code.
3. The spring framework finally recognized that with Modulith.