This book explores the XP hype and discusses the problems. In the end the best parts of XP will be used in the writers own software engineering process.
The first part gives a summary of the XP process and the problems with the c3 project of Daimler-Chrysler. This is the project that is talking about to prove Xp can be used in larger projects. By using excerpts from a number of wiki resources they tend to show the problems with the c3 project. The following resources are good to read.
Interesting wiki page, fun to read. But the finesse is at the end. In fact the most important part of the part is rewritten about 15 times:
"Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren't the same. The customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance. This is bad, and we know it's bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system. Game over. Or not, we'll see..." -- KentBeck
The discussion whether the project is a success or not is hard. It did come to results within 11 months that are still used. Other projects trying the same did not succeed at all. However 4 years of hard work did not nearly reach the state of providing the complete system. I guess Xp is hard to be used in a project that takes longer than about 3-4 months. But the biggest problem is the lack of design and specifications. I believe in the goal oriented design and the use of personas. See the book "The inmates are running the asylum".
The stuff of Xp that is very good to use:
test-driven development, continuous Integration, Coding standards, release soon and often, interaction design and pair programming.
One important remark for pair programming, use it wise. I have the same opinion as the writers of the book. Only use pair programming for the hard part of your system.
The following excerpt from the book made me laugh, but I think it is very close to the truth. "XP is a methodology creates by programmers who are sick of management telling them that they can no longer just code, but they must follow a formal methodology. XP's main tenets are all very programmer-centric and often fail to consider the larger scope of a software development project."
This something we have to learn from within our gridshore philosophy. We must take care not to make it a programmers game. We need to have good designers (interaction, interface and software) as well.
The final chapter of part one discusses what can go wrong with the XP process. This chapter introduces the concept of the circle of snakes. Each snake represents one the practices of xp. What makes it interesting is that each snake can only be made safe by daisy chaining it to the next snake. I'll give an example by one of the snakes.
Emergent design means that very little time is spent designing the system before coding begins. The overall design and architecture will morph many times in the course of the project. But the lack of significant upfront design is considered "safe" because the code is being constantly refactored.
Why is this rng so interesting, since failing with one of the snakes makes the complete process instable. It is very hard do all snakes right, therefore the process is hard. A process should not be hard to use, if one of the snakes fails the process should have contingency build in.
- One step builds (using a standard directory structure, building with ant, automatic unit tests with junit and ant)
- Schedules builds (using cruisecontrol builds are created on time with reporting as well)
- Push button releases (version control systems are important, a release contains executable code as well as documentation)
- Installation and deployment
Every part is discussed while using a tool. A few important remarks from the book:
CRISP builds :
Complete - No manual actions necessary to create a build and run tests
Repeatable - You should be able to recreate previous builds
Informative - If a build fails comments should be as obvious to find the problem
Schedulable - It must be possible to schedule a build on a certain interval or at a certain time
Portable - It should be to difficult to port the build to another machine
A remark that is made about releases, is: Release early and often. It is very important to test your release procedure as well as the releases as early as possible. It is good to have a daily release. (Nightly build)
There is also some help on installation, a good advice is to provide customers with some kind of test application that reads the configurations, and checks if the application is installed correct. This can provide you with just the right amount of information to get to the problem quickly.
It was a very fun book to read and good to complete or start your 'Project Automation'
While performance testing we came by the following tool for performance tuning apache.
When using apache you can do a quick performance test with a programm that can be found in the bin folder. This is calles ab.exe.
Example command : ab -n 10 http://localhost/login.jsp
C:\>ab -n 10 http://localhost/login.jsp
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.4 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Concurrency Level: 1
Time taken for tests: 1.390643 seconds
Complete requests: 10
Failed requests: 0
Write errors: 0
Total transferred: 54960 bytes
HTML transferred: 49270 bytes
Requests per second: 7.19 [#/sec] (mean)
Time per request: 139.064 [ms] (mean)
Time per request: 139.064 [ms] (mean, across all concurrent requests)
Transfer rate: 38.11 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 93 138 43.2 140 218
Waiting: 93 135 41.7 140 218
Total: 93 138 43.2 140 218
Percentage of the requests served within a certain time (ms)
100% 218 (longest request)
This book from Alan Cooperdiscusses the advantages of using goal oriented design to create good products. I think it is a must read for all programmers, designers, project leaders and managers as well. By using a lot of examples from the field, this book explains why designing your software is important and why you must use specialist to do the job. But beware, some parts of the book might be to confronting to some readers.
The first part of the book introduces you into the dancing bear and cognitive friction. Cognitive friction deals with people feeling stupid while using products like tape recorders, tv sets, computer programs, etc. This all has to do with the Dancing bear products.
A dancing bear is someting wonderous to see. Not that the bear can dance well, but the fact that it can dance at all. The same is valid for a lot of software. The programs don't do a good job, but the fact that it works and makes the users life much simpler makes him forget that it can be even better. This is what is called cognitive friction, the fact that products we use on a daily basis are hard to use. People dealing with cognitive friction tend to fall into two groups:
make excuses for the creators since they can make the programm do something they could not do before.
they know something is radicully wrong, but they do not know what.
The apologists say, "look a this, a dancing bear!". The survivors say, "I need something that dances, so i guess a bear is the best I am gonna get.".
Ofcourse the solution for the dancing bear is a good design upfront.
The second part of the book is interesting from a project management perspective. One of the issues is about deadline management. To often managers rather ship a failure on time than risk going late. If the product is great, being late is not a problem very long. Another issue with deadline management is the requirements. How many of you have working with these long feature lists. To often programmers determine how long it will take to implement a feature. Then some of the features will be out of scope and others won't. Programmers have a very big influence on this process. It would be way better to let the Personas goals determine which requirement is within scope, since these goals are the only important thing for the product. If you find it hard to separate features from goals, the book gives a nice example:
Students must write down the type of product as soon as possible based on provided features.
1. internal combustion engine
2. four wheels with rubber tires
3. a transmission
4. a steering wheel
A lot of students will now write down a car, then the following two goals are given
5. cuts grass quickly and easily
6. comfortable to sit on
Therefor goal oriented design will point you to the right direction and most often better solutions.
The next section explains why programmers 'Homo Logicus' can never be good designers. This was sometimes confronting to me, and therefore a very good read. One thing that I remember is that programmers use the implementation model for designing user interactions. This way the program does not mirror the end users goals, it reflects the mechanisms within. The most important part is that programmers create programs they would like as users. They put in a lot of features that they think are cool or good to have. Usually these do not support an end users goal.
Another problem in the current software world is that most of the project leaders are former programmers. Designing is not there nature. If a designer is on the team, most of the time he is not the one taking the desisions about what is in and what not. In the end it is the programmer that has the power. He takes the design as a guidance, while it should be the law. This way, if you have a designer, he can create the greatest design, but it must be followed by the programmers.
The next part of the book is very interesting. It gives you some guidelines about the way to get a good design.
The biggest thing to talk about is the creation of personas. From conversations with the stakeholders a number of personas are created. One very important thing is that the end user does not directly affect the solution. It can only be that one of the personas get an extra or more specified goal. Personas are not real people. The personas have there goals in there work. When designing a product usually a large number of personas are taken and they should all be satisfied. It turns out that this is wrong. The best products are designed for 1 persona. Let me explain this with an example. As a car company, you want to create a new car. You have three personas: Wendy is a mother of three children, she uses the car to get the children to school. Fred is a salesman that uses the car alone and is a lot on the road. He likes to ride sportive. Then we have Henk, who has his own construction company ans needs to take a lot of tools with him. Trying to please them all would lead to a very strange car: a convertable van with room for kids and large tools. It would be way better to create three different cars. The same is valid for software. You need to define your primary personas. These are the personas you design for. You can have a maximum of three primary personas per product. In theory you should design a different interface for each primary persona. When documenting the requirements for the system, you do not write down features anymore, you create personas and there goals.
The books continous explaining about the goals the personas can have and how to find these goals:
- Personal goals (not feel stupid, not make mistakes, have fun)
- Corporate goals (increase our profit, defeat our competition, offer more products or services)
- Practical goals (avoid meetings, handle clients demands, record clients orders)
- False goals (run in a browser, be easy to learn, speed up data entry, use cool technology or features)
The final part of the book tells you more about designing with the software development process. The most important lesson here is to design first and well, stick to it while programming and create good products.
This is a very short introduction into the book, I am very enthousiastic about the book. Ofcourse you can find it at amazon, please use the link below and support me.
Hi all, great that you found our blog. This blog will be used to enter news and activities from this website. I hope you like the website, please use email to give us comments. It is also possible to give comments after each message.