Fortsätt till huvudinnehåll

Plan to throw one away

One of the chapters in the famous book "The mythical man month" by Fred Brooks is titled "Plan to throw one away". The idea is that you should plan to throw the first version of your software away, and then re-write it the way it should be. It is very likely that you will end up with a better written product and the total time spent will be less than it would have been trying to fix all mistakes you made in the first version.

It might sound counter-intuitive, but throwing the first version of the product might save you both time and money.

It should be noted that the first edition of the book was published in 1975, long before agile software development techniques and things like Scrum became the reality of every software developer. However, with Scrum we've seen to forgotten this completely. We do not plan to test things out for one sprint, then throw it away and do it correctly the next. No, we want to deliver costumer value every single sprint, all the time. The effect being that we are effectively killing innovation and forcing the developers to continue building new features on bad solutions.

The developers needs to be allowed to have sprints, a lot of sprints, where the resulting code is thrown away. The goal of such a Sprint should not be to produce costumer value, but to let the developers learn and try things out. So the sprint after that, they can produce real costumer value and keep the code base in a shape that allows them to continue doing that over and over and over.

Remember, the first version of everything will probably stink. Don't be afraid to throw it away and do it the right way.

Kommentarer

Skicka en kommentar

Populära inlägg i den här bloggen

Codility tasks - Part I

I was recently faced with two codility tasks when applying for a job as an Embedded Software Engineer. For those of you who arn't familiar with Codility you can check out their website here:  www.codility.com Task one - Dominator The first task was called Dominator. The goal was to, given a std::vector of integers, find an integer that occurs in more than half of the positions in the vector. If no dominator was found -1 should be returned. My approach was to loop through the vector from the first to the last element, using a std::map to count the number of occurences of each integer. If the count ever reached above half the size of the vector I stopped and returned that integer and if I reached the end without finding a dominator I returned -1. So was that a good approach? Well, the reviewer at the company rated the solution as 'pretty ok'. His preferred solution was store the first integer in the array and set a counter to 1. Then loop through the remaining i
7 kommentarer
Läs mer

C# Enum as bit field

Bit field enum Whenever you wish to express combinations of properties of an object, bit fields are a good way to accomplish this. As a simple example, consider a file in the file system. It can be Readable , Writable , Hidden or a combination these. The different attributes can be defined as an enum : [Flags] public enum FileAttribute {   None      = 0b0000;   Readable  = 0b0001;   Writeable = 0b0010;   Hidden    = 0b0100; } To indicate that this enum is expected to be used as a bit field I have defined it with the FlagsAttribute . It is important to understand that the FlagsAttribute does nothing more than making some changes to how the ToString method of the enum works, making it possible to print out all flags. It does not introduce any validation or special treatment of the enum in any other way. I have defined the values of the different fields of the enum using binary representation, this should make it even more clear that this is a bit field and which bi
Skicka en kommentar
Läs mer