--Originally published at TI2011 – Miguel’s Blog
This is the final reflection for the course. This will first cover the topics that the last third of the book covered and then I’m talking about what I learned from the book as a whole. One of the first topics covered in the last part of the book is that some projects often skip the design process. Well, design will be done, but when implementation comes around, the programmers will just not look at the design and design as they code, which can lead to a high number of bugs. It’s also discussed that sometimes it’s better to just do design for a long time, try to get the best design possible and that design should be easily transferable to code. Then you can do last minute implementation and end up with few to no bugs. The problem with this in the context of the book is that the teams were overstaffed and design is a process which will not be sped up by adding more people, it might even slow down. When coding, more people can often reduce time. A dynamic team size throughout the project’s lifespan is the best way of doing it. Personally I think this is true, design is difficult to do with a lot of people, you have to communicate with many others when doing something that the time that you actually spend doing design decreases.
Another topic that is covered by the book is the size of meetings and the way meetings should be carried out. A meeting agenda must be defined beforehand. Not all meetings are relevant for all people, so having someone in a meeting that serves no purpose to them is only wasting their time. It’s also mentioned that there are some steps to take when starting a meeting. This
