It has been more than a month since our last post about the screenings of Uncle Bob’s video presentations (organized by the Łódź Java User Group) that we’ve been happily attending. During this time, we had the opportunity to watch two more episodes in the series.
The first of these episodes continued on the topic of Test-Driven Development (introduced in the previous episode) and Uncle Bob’s approach to it. He addressed a number of arguments against TDD – I won’t go into the details, let me just say that Uncle’s counter-arguments were very convincing. In addition to that, a complete example of a bowling game program written with TDD was presented (this example seems to be quite popular as a demonstration of TDD).
Our team is currently participating in one project that makes extensive use of TDD techniques. For me personally, watching Uncle Bob’s videos on this subject was a good learning experience. Of course, this won’t transform you into a TDD expert overnight – there’s a ton of things to learn about writing tests, and even more about writing good tests, but I’d definitely recommend the videos as a starting point.
The next episode in the series was devoted to the concept of software architecture, and the myths around it.
Uncle Bob presented his philosophy that software architecture is not about the selection of the right tools (e.g. an IDE), solutions (e.g. a specific DBMS), or technologies (e.g. an application framework). According to him, it’s all about the use cases (or, if you prefer, user stories) and having a good understanding of the purpose of the software that is being built.
Expanding on that idea, the source code of the software should clearly represent what it’s for. A programmer should be able to quickly identify that he’s looking at, e.g., a payroll application, rather than noticing that it uses the MVC pattern or is built upon a particular framework.
Uncle Bob believes that programmers and software architects should learn to decouple the layers of the system as much as possible, and be able to defer the decision of which framework/database to use until later in the project. The system ought to be designed in a way that allows for easy replacement of these components.
One point brought up in the video that I considered crucial was that software architects should also actually write program code. Understanding the business needs of a client is not enough to be able to design a robust software system. I think the most desired skill for a good software architect is the ability to work with both the business perspective and the technology perspective in mind.
To be honest, the overall ideology of software architecture presented by Uncle Bob seemed a bit demagogue-ish to me, but I guess that’s often the case with areas where business needs and technology overlap. If you are a programmer whose job is simply implementing parts of the system according to the provided specs, then the philosophical lecture on software architecture won’t be of much use to you, and you can probably skip this episode of the series.