We started this episode discussing about readability of code. What actually is readability? It seems, that next to names, there are other important things to consider, like visual structure. In the second part we talked about how to get started with Test Driven Development (TDD) in a project were nobody else is doing it. We found a few suitable ways to get things started. Finally we concluded the episode with our personal history, how we each one of us got started with TDD.
How bad is duplication on different levels? When should we prefer having some code in our codebase over taking the dependency to a library? Is all duplication equal? In the first topic of this episode we discuss several aspects of duplication in a code base and the impact on stability, maintainability and reliability. For the second topic we discuss some schools of software development, from eXtreme Programming to Programming M.F.. Do they support different personalities of team members? Or should we try to consolidate on a single school within a team? For the last topic we don't feel to have a proper conclusion. So - what are your experiences on schools of software development. Interesting discussions guaranteed!
In this episode, we were discussing the (i) additional cost of following BDD. We concluded that the core of BDD is the understanding of what needs to be done and as such, it can be compared to TDD or ATDD. Maybe there is no additional cost, rather a cost of not doing it. During the second part, we focused on the question of (ii) being a generalist or specials. What impact this decision has on career, teamwork and project success and whether there is a preference for us.
In this episode, we tackled two topics: (i) How we meet the requirements of constantly learning new technologies and what approaches we use to drive this efficiently. In addition, we try to find a common understanding, at which point in time something can be considered as known or learned. After this, we take hold of (ii) the occurrence of accidental and essential complexity in software projects described by Fred Brooks. Why it's important to understand the difference, and what we can gain from this knowledge.
The SOLID principles were proposed by Robert C. Martin to make software designs more understandable, flexible and maintainable. During our first podcast Paul, David and Christian will dig deeper into these five legendary design principles and discuss which experiences they made by using them during their daily work.