Also available in Czech, kindly translated by Aleš Roubíček
Writing Legacy Code* is a distributed activity.
*In Working Effectively with Legacy Code Michael Feathers defines Legacy Code as “Code with no tests“, which reflects the perspective of legacy code being difficult to work with. I’ll stick to this definition.
Oh, no! Bad code again
You have been assigned a new task.
Your mission: to add a simple feature to a Corporate project. You know almost nothing about it, but the feature request sounds feasible. You can easily accomplish the task.
I agree with Michael Kennedy when he says that Software Development could be modeled as a Knowledge Discovery Process, “the process of going from 0% knowledge about an idea to 100% knowledge of a finished product ready for delivery to a customer“.
I agree so much that I decided to adapt my future Daily Scrums to this.
Some weeks ago I gave a talk at AgileDay.it. My talk was about a weird experimental Kanban board, and the Leitmotiv I used was around the differences between Principles and Rules. The topic was: we often learn methodologies mocking rules (often, without getting the point) rather than trying to understand the principles behind them. This bad habit sometimes leads us to take really dumb decisions.
Well, if only I had seen then what I saw today, I would have used in my talk, since I think it would have been the perfect example.
See what I found in a recent production code.
Right now, it hangs on the wall of our open space, for all the developers to see.
Luckily, your estimation meeting will be much more fortunate than mine (see Part I).
In my previous Scrummerfall experience, since I was forced to produce a big-planning-up-front phase, I was used to always plan 2 or 3 days for it. I was asking for an estimation when my ignorance of the problem was at the maximum level, hence I needed a lot of analysis.
I once worked as a team leader in a startup. I was in love with XP, studying Scrum and looking forward to be able to put into practice what I was reading.
Unfortunately, my boss explicitly told me to use Waterfall. I never blamed him: before him, the company had no process at all, and was governed by anarchy; no documentation, no requirements, no clear roles. Actually, introducing a Waterfall process, he made a great revolution, and let the company succeed. Continue reading “Why you should learn some Waterfall as well”→
There must be something very wrong with me: for the first time in my life I think that Martin Fowler is wrong on a specific topic. And, since Martin is Martin and I’m just a humble developer (Arialdo who?) I’m likely to be the one who’s completely off the track.Nevertheless, unfortunately, no matter how much I dig into the topic, I’m not able to convince myself that Martin Fowler’s arguments about Feature Branching, Continuous Integration and Feature Toggling are right.
When a unit test for a method implementing some feature is green, it does not mean the feature is working. The corresponding end-to-end or integration tests reveal if it’s working or if it’s broken. To Product Owner’s point of view, end-to-end tests are all that matters. Unit tests are useless.
Unit tests are meant to lie. They rely on the often wrong assumption that the rest of the world is correctly working, but only because they are explicitly mocking it: using a fake world is a deliberate lie.