Architecture
-
SCRUM ONLY WORKS IF WE UNDERSTAND THE BIG PICTURE
Scrum teaches us: ”No big bang design!” We’re supposed to discover the design as we keep developing. Sure, that’s probably ok in a small project. It’s like building a small medieval village. Another villager moves in and just patches his house on the outside of the village. And after a while, we have a jumble of streets and houses. Try scaling up that to a big city! As soon as any software starts getting useful… eh… I mean bigger, we have to know what we are constructing. We have to take the time to sit down and think about what we are doing. We have to understand the problem we…
-
YAGNI – YOU AREN’T GONNA NEED IT! WHAT DOES THAT MEAN FOR SOFTWARE?
Never write a single line of code before we really know that we need it. Don’t rely on experience from other systems we’ve written. A new project is never an exact copy of the old one, or there wouldn’t be a need for it. And a software project always changes the specifications during the process. Two facts that tells us that we have to wait to write the code until we really know that it is necessary. Or we will write code that we Aren’t Gonna Need. Waterfall or Ad Hoc? Neither! All software is developed with a goal in mind. An end product. A vision of what we want…
-
HOW DO I WRITE A UNIT TEST THAT IS READABLE? DESIGN PATTERNS IN TESTS.
Writing unit-tests is not only about having a safety harness that catches the bugs that we create. It is just as much about making it easy for us to find the bugs. We want to write the tests in a way that they point us to the bug with as little effort from our side as possible. We want the tests to do as much debugging for us as it can. And of course, there are design patterns for this too. Code is never finished. We always add more features, change things, or just refactor. It’s part of our normal workday. But changing tested and delivered code is risky. Code…
-
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…
-
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 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…
-
TESTS ENABLE CHANGE!
Unit tests are about facilitating change! Yes, tests find errors in the code, and it is nice to know that your code is working when you have delivered. But that is just a fraction of the benefits you get from tests. The biggie is that you can change your code and still be certain that it does what it’s supposed to do. Code is always evolving. From the first line you write, and never stops. And I don’t just mean that you refactor your functions. That too, obviously, but all the way up to really changing the code, breaking it up and repurposing it totally by reusing what you have,…