-
Why do we have retrospectives?
A retrospective is a tool in Scrum, to make the team look at how the process can be improved.This is done by repeatedly looking at how we do things today and see what we can change. By doing this on a scheduled time after the sprint, the team is not distracted and can relax and focus entirely on the improvement. I have been to a lot of retrospectives that didn’t really provide any use to the team. Sure, it’s nice to get together, especially when most of us work remote. But that’s not why we hold a retrospective. I’ve noticed that so many really doesn’t know why we do them.…
-
STOP THINKING ABOUT IT, START DOING
In my entire life, I’ve always hatched ideas of things I want to do. Everything from small things to grand projects. But most of them has never moved past the idea stage. I would say that I’m not the slightest unique in this. It is easy to come up with an idea, but it is hard to realize it. Especially if I don’t know how. For every entrepreneur out there, this is a weird statement. This is in their blood. They get an idea and just run with it. But for the rest of us, we need to learn what to do. So, what was I missing? It all started…
-
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…
-
SCRUM IS A BIG CHECKLIST TO INCREASE QUALITY AND SPEED
Checklists are good. They make us remember things. Especially when it is things we do over and over again, when it is easy to forget one step just because we’ve done it so many times already. I mean, we’re just human. If we look around, many operations where risk is high often use checklists. Like pilots. They are fanatic when it comes to following the pre-flight checklist, because if they miss anything, even the smallest thing, it could end in disaster. Lives are at stake. But few airplanes go down because of pilots skipping this step. I think it’s safe to say that checklists work. They evidently increase the quality…
-
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 TO CREATE A TEST FIXTURE
A test fixture is used to:● Make the code less brittle. We isolate the construction from all the tests and only do it in one place, so when we add a new parameter in the future, we only have to change the test code in one place.● Makes the job of writing tests easier, we write less code because we only call a function that creates the instance, instead of writing the entire construction with all the parameters in every test.● Make the code DRY (Don’t Repeat Yourself). We only do the construction, the newing up, in one place. The code Moq is used in this example. Obviously, there’s nothing…
-
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…
-
ARE ALL BUGS CRITICAL?
Often when you listen to people that report bugs, it sounds as if the world is coming down if it isn’t fixed immediately. But are all bugs really that serious? Is it possible that some of them actually doesn’t have to be fixed right now? That we even could put them into the backlog? There are two kinds of bugs. The ones that has to be fixed right away or the world will burn. And the ones that are annoying, but you can live with them. The first category has to be fixed immediately, obviously. But the other one can safely be added to the backlog and handled like any…
-
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,…
