Episode 150?: Uncle Bob´s tips for Software Craftsmanship


In this podcast, we heard Bob (better known as Uncle Bob) talking about Software Craftsmanship, a very interesting title for what the architects (should) do. The first argument that Bob tells us is the one I will be focusing on this article; the best kind of architect is the one who codes. So, what did Bob meant with this?



As we have talked about on the past entries, there is a big distinction between a boss and a leader; being the latter the one that brings some kind of balance between directing and acting. While the boss is the one that only points at what needs to be done, the leader works with the team towards that goal. Bob points out that the separation of leaders of the team from coding is a huge problem, that’s why architects must get involved with the work that is being made.

Why is this important? Because leaders that don’t get involved make critical decisions and then unbind themselves from the project. This “urge” to get everyone involved in the project is the reason why EX programming and the Software Craftsmanship surges. Something curious mentioned in the podcast is that the Manifesto for Software Craftsmanship is based on the Agile Manifesto, but with some added features; focusing on well-crafted software, steadily adding value, building a community of professionals and get productive partnerships.

Something curious that Bob pointed out, was the importance of, not only knowing about the programming language you are using, but also know inside-out the IDEs used. This helps making faster code, quicker debugging, and applying other tools the IDE may have. And one final observation was the importance of getting to know one dynamic, static, functional and one logical language, as getting to know how each “paradigm” works will improve the way people code and how they approach challenges.


Finally, the important part of software projects that needs to be stressed out is that software leaders shouldn’t be segregated from the coding teams; architects must act as a guide for the whole team to tackle obstacles that initial “planning” could lead to. It is utterly important that leaders can help by, not only proposing ideas, but implementing them. 

References:
Martin Robert (2009). Software Craftsmanship. Produced by Software Engineering Radio, available on: http://www.se-radio.net/2009/11/episode-150-software-craftsmanship-with-bob-martin/

Comments

Post a Comment

Popular posts from this blog

Chapter 4: Architectus Reloadus vs Architectus Oryzus

Image
So, who needs architects anyways? Here lies one of the most important roles in the software world the unstoppable Architectus Reloadus. After reading the article, it reminded me of an image picturing 2 groups of people; each group having either a boss or a leader commanding them. While the boss was just instructing where to go and what to do, the leader was working with its group. This is the same analogy we get in the article with the 2 types of architects mentioned, the  Architectus Reloadus  and the  Architectus Oryzus . Architectus Reloadus  is the architect that proclaims himself as the  most important part of the project , as the design is made only by him, leaving the other developers to follow. While the  Architectus Oryzus  works within the team to improve the team’s level so they can approach harder and more complex issues. In other words, the Architectus Oruzys  is a guide, skillful enough for being the anchor of the team, and clearly selfless, as he works at the
Read more

Chapter 9: Microservice Architecture: A whole new Architectural world.

Image
After reading the article, I started relating microservice architecture with the activity we made when we talked about components and Lego bricks in class: This type of architecture is made of smaller and independent services that are linked together to form a concrete service. With the image below, we can see a clear representation of how this is conceptualized. However, there is a small detail that separates microservices from monolithic services; while the later gathers all functionality into a single process, the microservice separates each part of the functionality into a separate service, allowing scaling with distribution of the services, replicating as needed. This is the aspect I liked the most; low key planned modularity for software architecture (or at least that’s how I see it) There are a lot of interesting features of this type of architecture (with a heavy approach to encapsulation, as I dare to confirm), such as Componentization via Services, Organized ar
Read more

Chapter 11: Metaprogramming

Image
The last article read was “An Introduction to Metaprogramming”, an interesting article where Ariel explains the concept and some examples of metaprogramming. Starting of describing the different types of metaprograms, like compilers, interpreters, parser generators, assemblers and preprocessors, metaprograms come in many shapes and forms, which main goal is to eliminate or reduce error-prone programming tasks. I have heard of this concept as a utopic approach to things, however, I haven’t seen metaprogramming first hand. At first, I thought it was a really complex way to do things, but after reading the article, it doesn’t go that deep into weirdness. Beginning with the first example; it clarified how the concept of metaprogramming works, a script that wrote another file with the code expected. While the ruby snippet shown was not some other world stuff, but the example is pretty clear, we can write codes through code. Now, the second example goes a little bit deeper
Read more