-
DOES UNIT TESTS IMPROVE THE ARCHITECTURE OF MY CODE?
This might sound like a silly question, but what do you use unit-test for? It is not as obvious as it sounds, given that the word “test” is in the name. It makes us believe that they are used only for testing, doesn’t it? And to some extent, that’s true. But that is not the full story. They are giving you so much more value than just that. For instance, it changes the way you write code, it changes the architecture. Writing unit tests forces you to write testable code. That makes it easier to read and understand, it tells you what it does instead of hiding things in gigantic…
-
SOFTWARE IS ORGANIC, ALMOST ALIVE, AND THE TEST SUITE IS ITS IMMUNE SYSTEM
Contrary to things made in a factory, software is never finished and put into mass production. We never stop adding features and evolving it. It reminds of a living thing. And living things needs an immune system to survive. That is what the tests suite is! Your defence against the continuous deterioration that constant tinkering brings. Software is never finished. The idea of industrial production, when we construct a thing, and then make loads of copies of it, does not apply to software. The industrial way of thinking is that when we have a need, we make a thing. If we have another need, we made another thing. For instance,…
-
UNIT TESTS ARE ACTUALLY TESTING REQUIREMENTS, NOT CODE
A unit test sees the code it tests as a black box. Its only concern is to verifies functionality. It really doesn’t care about how the functionality is realized. It actually has a much tighter coupling to the requirements, because if they don’t match, your out of luck. We test functionality, not implementation details When we write a unit test, we are testing functionality. I’ve said it many times before, but it is important to understand. We do not test code. The test doesn’t care about how the functionality is implemented. But what do I mean by that? This is my definition. When we test the code, the test-code is…
-
ROUTINES REDUCE FRICTION AND GETS THINGS DONE
It is always a good idea to remove as much friction as possible. And with friction I mean the resistance to get things done, to start and to keep doing it. There are many ways to do that, and one of them is to have routines. But what does that have to do with Scrum? Routines are learned behaviour. An order of operations that you don’t have to invent every time. You just know what to do next. This speeds up things, and it consumes less energy. Scrum is actually a set of routines that removes friction. Scrum is a well-defined process. It has several pieces that build a pipeline…
-
WHAT ARE NEGATIVE UNIT TEST, AND SHOULD I BOTHER WITH THEM?
I don’t thing anybody has missed the fact that unit tests increase the quality of the code. But then someone starts talking about negative unit tests. What the heck is that? A unit test verifies that the functionality in the code works as expected, but don’t forget the other side of the coin. Errors. And negative tests verify that your code doesn’t get stumped when an error occurs. Here are a few things that helps you write them. Stable code doesn’t break because of errors Code, like life, never works out the way you intended. There is always a lot of stuff happening outside of our control. For software, we…
-
WHEN IS THE USER STORY “MAKE IT BETTER” FINISHED?
We’ve all been told to do the system safer, better looking, faster, or any other vague requirements. So we do what we think solves the problem. But it wasn’t really what the stakeholder wanted. Can we avoid this by quantifying what better means, by putting numbers on it and measure when we are done? The users probably don’t know what they want. Don’t be satisfied with that. Ask questions and clarify the intent. Then make it measurable so you know when you are finished. And yes, you can quantify everything. Why are requirements vague? We don’t know when we arrive if we don’t know where we’re going. A vague requirement…
-
WHO IS THIS “USER” THAT SCRUM KEEPS TALKING ABOUT?
When you see an example of a user story it always stars with: “As a USER…” But what hides behind this “user”? Who is s/he? Or what? And does it actually give me any value to start every story with a user? The “user” is way to generic. Instead, you should be specific. Who, or what, makes the request? By identifying the stakeholders up front, you stand a much higher chance of making a system that actually works. So, what is a stakeholder, then? The problem with Scrum, according to Tom Gilb A co-worker woke my interest in what Tom Gilb has to say, a while ago. We were sitting…
-
THE SPRINT IS ACTUALLY A SET OF GOALS
People with goals always outperform people without them. I think that this is the main reason to begin setting goals. We all work better if we have a goal. That is, goals that we commit to, make a promise to ourselves that we will finish. A goal without this is not a goal, it is just a waste of time. What’s the point if I set a goal for myself and then just ignore it? We have to hold ourselves accountable. Now, the goals has to be reasonable, you have to be able to finish them, or they are just as useless as not having any. Setting a goal to…
-
THE REFINEMENT IS NOT JUST AN HOUR LONG MEETING EVERY SPRINT
User Story Refinement – The activity of understanding what is asked of us, and the decision making of how to do it. There refinement has two parts. The first part is to make sure that we understand what the stakeholders want. What are the problem we’re trying to solve? We have to understand how the story fits into the big picture, we have to understand how the thing we are going to do is going to be used by the stakeholders. Not the stakeholder (singular), because there are of course many stakeholders. Obviously, there is the client. The one we talked to when the story saw the light of day…
-
SCRUM – THE BIG MOTIVATOR
When we read about motivation and what makes an organization effective, we often find that the control over one’s work and time is at the very top. We see this in for instance 3Ms 15% rule. Or for that matter, flex-time has the same goal. I even think I heard about a company that had no required work hours at all. Or how about having the possibility to not have to work at the office? This is also one of the big reasons when people start their own business. To take control over their own time. It is not hard to see that if you choose to do something you…