Gridshore software engineering weblog - Books

Last entry ...

nospam@example.com (Jettro Coenradie) — Sat, 19 Jan 2008 20:58:56 +0100

Welcome to the last entry of this blog. No I am not quitting, I am just moving. I just installed a new blog software framework. I was starting to dislike the way to interact and I wanted something that contained more out of the box. I am in the middle of moving to wordpress software. There is a very good reason to do this. I had found a great tool on the mac called MarsEdit. And again this could not be used with serendipity. I hope I did make a good choice. Since there is a lot of information in the old blog, I did not take this blog offline. It will stay to exist, but I will not make changes there anymore.

I hope to see you at the new version of the blog (check the page at http://www.gridshore.nl). You can attach you feedreader to the following url: feed://www.gridshore.nl/feed/

Book reading time - The myths of innovation

nospam@example.com (Jettro Coenradie) — Mon, 11 Jun 2007 21:48:56 +0200

Man, have I been busy the last few weeks. So much to do, so much to learn, so much to try. Within two days it is time for our presentation at the dutch NLJug. I have been setting up the osgisamples website. Upgraded the family website. For my current employer we are finishing a webservices project at a big client. After about 1 1/2 year it is time to go to a new client. The time to relax is starting to come back. I want to use more time to start reading books. Ofcourse no thrillers :-), but interesting books. So from now on you will see some book reviews on the website again. I hope you will get enthousiastic about the books. If you decide to buy the books, you can support me by clicking on the link on this website. This also gives me an indication if people like what I write about the books.

This time I want to write something about the following book:

This is not a programming book, no you won't find java in here, no webservices, but a lot of technology. The book is about innovations. How can you be innovative. Is it something you can learn? Was the gravity moment of Newton an epiphany, or is that not possible. Does the eureka moment exist when your innovative, or do you need a lot of time to prepare that euraka moment. The book uses a nice historical introduction and a lot of links to resources on the web to read more. Sometimes it is just fun to follow the links and continue reading there. The biggest problem is that you need some sleep. You can really get lost in all that interesting reading on the web. Just for the fun two examples of interesting links.
http://www.ideafinder.com/ - look for good initiatives and learn from the past
http://www.goodyear.com/corporate/history/history_overview.html - nice story about how something simple can influence the world.

Review Rafactoring by Martin Fowler

nospam@example.com (Jettro Coenradie) — Mon, 03 Apr 2006 23:12:48 +0200

The last few weeks I started reading about refactoring code. I always thought I knew my way around refactoring. I can use eclipse. After reading this book by martin fowler I think I misjusted myself. Sure I know the basic stuff. But after reading this book, everything falls in it's place. Now it becomes easier to talk to other about it and to start teaching myself and others about refactoring. The examples in the book are very thorough, some are a little bit to obvious to my opinion. Still I very much like the book, so this is a must read for every serious java programmer.

Review Planning Extreme Programming

nospam@example.com (Jettro Coenradie) — Wed, 25 Jan 2006 22:49:50 +0100

This is a book from one of the Xp guru's. Who am I to say, "I would not buy it". Still I dare to say it. Not that it is a bad book, but reading one or two articles is probably enough. I would invest in a book like Agile Software Development with SCRUM to learn about planning a project. And I guess you should read : Extreme Programming Explained : Embrace Change (2nd Edition) to learn about extreme programming.

Conclusion, this could have been said in about 10 pages as well. I you haven't read anything about xp this book might be interesting, but the two alternatives are better to my opinion.

Review Ajax in Action

nospam@example.com (Jettro Coenradie) — Sun, 22 Jan 2006 10:36:34 +0100

This is the second book about ajax that I have read. And what a book it is. If you want to go into the depth of ajax this is the book you want. Within this review I will explain why.

This book is devided into four parts:
Rethinking the web application
Some general discussion about website programming and your first ajax helloworld application. The interesting stuff already starts here. This is your first introduction into using design patterns in your javascript code. Excellent description of some of the more important design patterns are given. Even if you do not like ajax you can leanr something about patterns here.
Core techniques
Discusses the actual implementation of Model View Controller pattern within ajax. Some nice tips on javascript and style sheet usage.
Professional ajax
Discusse the more advanced Professional ajax side. Now we are learning about security, usability and performance. Also very interesting stuff
Ajax by example
Interesting if you want to learn how it really works, I'dd rather use an existing library, but it is fun to learn.

So this is a great book, with real live examples and a very wide coverage of the subject.

Foundations of Ajax

nospam@example.com (Jettro Coenradie) — Sat, 05 Nov 2005 23:50:39 +0100

It just hurts to put an article about ajax on my website, those knowing soccer teams in the netherlands will understand me. But nevertheless, I started reading this book mentioned above Foundations of Ajax. I have read the book and it has a high been there done that feeling. This has nothing to do with the book but more with my knowledge of Javascript and the DOM. About 2 years a go I did a lot with javascript and now this knowledge comes in hand. I think this is a nice book. I did not read anything about ajax until today, still the book is very easy to read (Mayby a little bit to easy if you have some prior experience). I do like the samples that are given, almost all classes and scripts are given in total and therefore easy to read and follow. A lot of screendumps clarify the examples. i gues the most interesting stuff is yet to come (the different toolboxes and unit testing your scripts). I also like the part where test driven Javascript development is discussed. The best part is chapter 8, a discussion of a more thorough example. A framework called Taconite is used to create a dashbord application. An example of using rss, word completion and using a webservice. The example can be easily deployed in a webserver.

I do have a note of critique, I think there is actually little theory in the book. I really read it in one week-end, so i guess it will take you about 8 hours fulltime. On the other hand that can be an advantage to

The book triggers me to find nice extensions for my websites, I cannot wait to try out some stuff in the book. I see this as a compliment. Well in short, I like the book and if you are clean in the area of ajax and want to learn something about it in a week-end, this is your book.

Within the next few weeks i will try some of the existing frameworks, I did have a short look at the demo from Matt Raible:
Matt Raible ~ Equinox and ajax

Hibernate in Action

nospam@example.com (Jettro Coenradie) — Mon, 18 Jul 2005 23:16:00 +0200

This is one of the best computer books I have ever read. It gives a thourough description of the hibernate ORM tool and it gives a very good introduction into Object Relational Mapping in genereal.

Having said that, lets have a look at the book.

A lot can be found about the Paradigm mismatch. It has to do with the different appraoch of persisting data in a relational database and working with a domain object model in an object oriented programming language. This mismatch is discussed in the first chapter, together with some alternatives.

This chapter is a must read for every serious OO programmer and designer.

The second chapter discusses the first steps into Hibernate. It talks about the SessionFactory, queries, callback intefaces, etc. Then it discusses the configuration in managed and non-managed environments.

Then the first tough chapter about the mappings you can realize with hibernate (oops, there is even an advanced mapping chapter). Interesting to see and read about the different mapping principles you can have like, associations, class inheritence and fine grained versus course grained objects. Interesting discussion about object identity and mapping the domain model.

In chapter 4 your going through the CRUD methods of hibernate, you will learn about the persistence life cycle and some optimizations. A very important part is the fetch depth. How many objects are you going to store in your internal memory.

The next chapter deals with transactions and concurrency, of course these are very important. I liked the caching stuff better. This is where you can get your optimization. it is also one of the hardest parts to design. A lot of choices to be made, you need to understand your application.

Then we go into the advanced mapping topics. Mapping types, custom mapping types, collections. The discussions of 1 to multi and multi-multi associations is very extensive.

Chapter 7 deals with querying your data effectively. How to do pagination, use comparison operators, use joins and write report queries. This chapter contains to much to grasp at once. The introduction of this chapter allready states to use it when it comes a long. You will be reading this chapter more than once, I assure you.

The last two chapters are about writing Hibernate applications and about tools that can help you.

To my opinion this is a very good book, 5 stars at amazon for sure.

Extreme programming refactored : The Case Agains Xp (conclusion)

nospam@example.com (Jettro Coenradie) — Wed, 08 Jun 2005 23:44:00 +0200

I made through the complete book. An interesting but rather long read it was. First some general remarks. I did like the book, well at least the first 100 pages. Then to me it was more of the same. The satirical songs and stories began to iritate me. The number of references to other parts of the book are way to much as well. Nevertheless, I did like the book, some conclusions are a bit harsh. The book gives some refactorings to the XP process to make it better. The best thing is that the book makes you think about your own process while developing software. Should you read this book? Tough question, if you have the time I would most certainly read it. If you do not have the time, you can allways jump to the conclusions of most of the chapters.

The book consists of a number of parts each containing a number of chapters.

Part I
This section gives a short introduction about XP. It discusses the values of XP, the 12 practices, the roles and the activities.

I think the best lines that tell you how the writers think about the book are these.

"XP is a methodology created 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."

The next chapter discusses the famous XP project C3. Some of the project members were Kent Beck, Ron Jeffries, Martin Fowler, Chet Hendrickson and Don Wells. There are a lot of quotes and references to the wiki website and to other resources on the web. This way you can create your own opinion. 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.

A few of the most interesting links are:
http://c2.com/cgi/wiki?CthreeProjectTerminated
http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation

Chapter 3, the final chapter of this part introduces the twelve serpents and the circle of snakes. What they want to tell you is that every snake is made safe by the following snake, if one snake is let loose, the circle brakes and all snakes are on the run. The remainder of the book will discuss the snakes and refactorings that makes the process safer. The snakes are:

No detailed written requirements.

Emergent design

Constant Refactoring

Unit tests

Pair programming

Collective ownership

on site customer representative

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. So if refactoring fails ....

They make it pretty obvious they do like some concepts, but you need to refactor them for your project.

One thing that made me laugh in the book was there way of discussing the 5 o'clock go home, anythin not done, throw it away XP practise. The following satirical quote makes it clear.

Child : "What did you do today, Daddy?"
Father : "I tossed out my code and went home clean. And tomorrow I intend to pair program and stare at someone else typing."

Part II
This part is about the social aspect of XP. One of the things that remains in my head when reading this chapter is bout the blame when the project fails. Within XP it is the people who are to blame, since the process is good. If you think bad about the process, you are in fear.

Onsite customer
The red line within this chapter is that being a customer is hard. Youe need to provide the requirements on story cards and prioritize them. You need to write runnable test scripts. When the project becomes to large you need to have a team from the customer. Because there are no written requirements the customers needs to talk with one voice. The solution is to have a customer available to an analist. The analist takes care of the requirements by analysing the customers needs and goals.

Pair programming
Pair programming can be helful when looking at tough problems. Pair programming with 100% of production code is extreme. People just cannot handle it being in one persons space with two persons all the time. On top of that pair programming is not the same as peer review while both are targetted at getting better code.

Oral documentation
One of the things programmers hate most is writing documentation. That is possibly the reason why so much programmers love XP. I think the following quote from the book touches the heart of the problem.
Fowlers quote highlights the fact that design documents in XP are mostly transitory. This contrasts greatly with the notion of design documents in, say RUP, which calls all items of ducomentation artifacts (which suggest documents that are long-lived and may be dug up several years later). Although this notion may at first seem absurd, the maintenance team who actually do need to dig up that documentation several years later will offer a prayer of thanks to the previous team members for their forward thinking.

Within RUP it is important to decided what to document. Ask yourself the questions: Who is going to use it? Who is going to miss it?

It does not take courage to stop writing documentation. It takes courage to take a product into maintenance without documentation.

Design after first testing
No BDUF - Big Design Up Front, this probably one of the biggest issues the writers of the book have with XP. I strongly believe that Design upfront is very important. This does not mean that writing tests upfront is wrong. Writing unit tests upfront does make you think about what to write before you write it. This also valid for design and analysis. Therefore test driven development is important, but equivalent to design upfront. In fact they complement each other. The chapters contains the following lines by David Van Der Klauw which I find interesting:

My concept of bug finding is something like this : A programmer should find 9/10 bugs before check-in, the automatic tests should find 9/10 remaining bugs before hand over to QA, QA should find 9/10 before handover to customers who will again find 9/10 the other 1/10 will never be found. Therefore the customer only sees 1 in a 1000 bugs

Morale, if you release to soon to the customer, he sees to many bugs and looses interest in the product.

Constant refactoring after programming
Refactoring is not bad, that is clear. However, constant refactoring code that works fine is not allways good. Why keep changing code just because it smells bad. So use refactoring when changes are necessary for requirements changes, bugs, or after a code review, but know when to stop.

Another thing about refactoring is UserInterface refactoring. Especially within XP, the users get to use the product very soon. But refactoring the UI makes the users look for functionality every release. When the users get to use the product soon, you also must maintain the live data. Refactoring also leads to a database refactor. Be very carefull with production data. Make solid migration plans.

User stories and acceptance tests
With all requirements the analysis is very important. Within XP User stories are used. These are very short descriptions of what a user wants to do with the system. Comparing these to use case (RUP) is obvious. What is missing with user stories is the failure conditions and actions, or the rainy-day scenarios. The step between the user stories and real code is large. You need to do requirements as well as design. The emphasize within XP is on Code. If the user story is not clear, use the customer representative to make things clear. Problem is this extra information is only documented in the code. Refactoring and you can loose requirements. No problem, if the customer representative does not miss it with his tests then it was probably not important. Another part that is hard to graps within user stories, especially since the customer should write these are the non functional requirements (FURPS+)

Part III, IV and V
To be honest, this is the moment where I started to loose interest. More of the same, sometimes in other words, there are a few statements that I want to mention and some good references.

Interesting subject about fixed scope, time, budget. This leaves just one parameter open and thats quality. You cannot make them all fixed.

Another thing that struck me it the use of frameworks. The book states this is not done within XP since you will never find a user story that tells you to use a framework. I cannot image this is true. One of the reasons I think that this book is to extreme itself.

They are also talking about Emergent Architecture, this is achieved via evolutionary prototyping that ends up as production code. Looking at RUP for instance, you have early prototyping, the code is not used in the production code. Usually this prototyping is quick en dirty, just to see that it works.

That's about it for the book. Hope this helps. I will use the gained knowledge to write down some theory in the wiki. I will close this review with a last quote, that applies to XP, but to some extend to the book as well.

I believe that a major flaw in XP is that it takes things to an extreme. I believe in doing things is moderation and trying to optimize the value by trading off one factor against another. In life, I fin that rarely is the optimum achieved at some extreme point.

Extreme programming refactored : The Case Agains Xp (part I)

nospam@example.com (Jettro Coenradie) — Sun, 22 May 2005 23:53:00 +0200

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.

http://c2.com/cgi/wiki?CthreeProjectTerminated

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 of the things they keep referring to is throwing yuor code away at 5 oclock if it does not integrate. see the following url for an image of the process
http://xp123.com/xplor/xp0006/index.shtml

I am curious what the book will bring in the following parts, more to follow ...

The inmates are running the asylum

nospam@example.com (Jettro Coenradie) — Wed, 18 May 2005 23:58:00 +0200

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:
apologist :
make excuses for the creators since they can make the programm do something they could not do before.
survivors :
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.