Back to school
Hola amigos! Today I've seen the best mug ever for my espresso coffee! Keep the calm and ramble on! I love Led Zeppelin!
Kinda strange day. I am back to one of the companies where my professional career adventures started almost 10 years ago! I was almost a rookie when I joined them and now look at me... I am still a rookie in many senses!
This company is based in Málaga so I offered myself to provide with Volunteer Services to help them to implement better Scrum practices given my experience in this area. This is also a way to earn SEUs that allows you to apply for the Certified Scrum Professional (see Category D). So is it really non-compensated work? Well I did not get a pence but It does not look like I am Mother Teresa either.
Anyway. What have we covered today? We went directly to the core, to the root. How a developer works on his day-to-day? What is the process of bringing a change request, new project developments into a customer?
In the outside world, people believe that Scrum "experts" are guys "that are very good in adding processes" and coordinate teams. Well, partially true or false depending on the context. Today we have only talked about managing the quality. OK, is quality management a process as well?
We covered
- Migrating source code control system from source safe to better systems as SVN or GitHub that can give the development team more flexibility and a more comfortable programming SCM.
It's literally a nightmare for the developers to have any sort of "collaboration" with many manual checks. "Are you using that file?". Difficult also to implement any sort of branching strategies on the source code.
- Code re-usability. This is a must-have. Companies tend to "Productise" themselves so they can avoid duplicating code, tedious copy-paste that makes the maintenance of the code a very complex task. This is not just creating a product to "govern them all". This is indeed "componentising" their modules. If the DB access is always the same in all your applications you are distributing to your customers, why copy&paste them? This is not just a better way to tidy-up your stuff. It has been demonstrated that will enforce a better quality in the code since you need to approach your modules as in an "API" system that provides you with services so you are also "ruling" your code from the base.
- Unit Test / TDD Approach. If someone asks me "why do you write unit test?" I will certainly reply: "This will ensure that I will write better code. This is a helper". What I usually hear when I first approach non-experienced unit test coders is:
"We don't need unit test, we are confident with our manual tests."
But would you like to re-execute all those tests every now and then whenever you commit a change?
1. A developer should write decoupled and independent code and those procedures added/modified have to be testable.
2. A developer should not worry in other than coding. The unit tests are re-usable and there are also quite powerful as they cannot fail if they are re-executed at anytime of our development process. If other change has been done over and it is breaking existing unit tests, our Continuous Integration or infrastructure is capable to flag that up and alert the developer.
They are also good metrics. And metrics are usually good. As I said, they are helpers, tools to ensure better quality. It has to be in the minimum set of tools. But not the only one. There is a myth around senior managers that believe that just having 100% unit test coverage will make your code the best in the world. This is perhaps the first step to improve. I can recommend "Clean Code" by Uncle Bob. This man is a real myth indeed. The book sentence:
"You are reading this book for two reasons.
First, you are a programmer.
Second, you want to be a better programmer.
Good. We need better programmers
Comments
Post a Comment