Mind the age and context of the book

Usually IT books don't age very well, things change very fast in the sector. This is specially true of books on particular tools, libraries, frameworks... but even books about methods and techniques require critical thinking when studying them. If the book is 5 or 10 years old, it's very likely that the author himself doesn't code the way he described in his book. We evolve as programmers - hopefully. However that doesn't mean that the book is no longer valuable. Many things are still valuable for sure, we just have to figure out what slices are useful today given our current context. Reasoning may be different if the programming language is not the same you use today, or even if its version is not the same. The paradigm may be different as well. Tools change and evolve very fast so unit tests written today, with all the fancy assertion libraries we have plus all the modern features of xUnit frameworks,  have to be very different to the unit tests you can find in a book written a decade ago.

I am currently reading a classic book, a great one from Martin Fowler Signature series - not written by Martin though. The book is terrific, I wander why didn't I read it then years ago! I am getting a lot of value from it, but I also notice certain old fashion techniques with well-known downsides.

I wrote a book on TDD 6 years ago. Since then my programming style has changed quite a lot. The way I do TDD today is different, and there are certain examples in the book that I even consider anti-patterns. I don't know when will I be able to rewrite it, although I wish, but the reality is that time flies.

Consider the age and context of books, don't just assume everything is valid today

SOA in Practice

Just done reading this nice book: SOA in Practice, by Nicolai M. Josuttis. I find it a good book to ask yourself if your architecture smells good or stinks. It does not include source code so it is more about the SOA tenets than explicit samples. Before reading the book, I thought that an architecture that uses web services was SOA, but Nicolai makes clear that "SOA is an architectural paradigm for dealing with business processes distributed over a large and heterogeneous landscape of existing and new systems that are under the control of different owners". The book lead me to think things like... "oh, so I am doing well here, or, I am doing bad, or , this service I've got here is a composed service, or a basic service"... However, I miss more explicit samples, specially regarding the Enterprise Service Bus. I wanted to read about the Sun ESB or the Microsoft Internet Service Bus, but none of them were even named.
So good book to give you some hints on your design but not such a good book for beginners. On the other hand, I believe that an scenario that requires SOA is not good for a beginner or junior developer. SOA is about common sense.

By the way, one of the bests talks I've ever seen on SOA is the popular "Patterns and Anti-Patterns for SOA", by Ron Jacobs. Check out the videos here:

User Interface Design for Programmers

User Interface Design for Programmer is a masterpiece written by Joel Spolsky in 2001. Although might be considered old, it is still absolutely useful and great. Some chapters are available online. I'd recommend this book to any software developer and also to advanced users because it is not technical, it is just a lot of common sense driven by example. This book is ideal for QA engineers and other people who review applications. Every paragraph is interesting.
Thanks for this book Joel, it is really good indeed. Thanks to Eladio for the gift 😉

Test Driven Development

TDD by Example is a master piece of Kent Beck. Excelent book with examples of this development methodology. I'd say that TDD is not that good without an architect, as usual, because you've got to decide the API, the interfaces you want as you write the tests and that is a matter of experience.
Ron Jacobs talks very often about his colleague Peter Provost. Peter gives a brilliant point on TDD in this video.

More links regarding TDD:

When you got the feeling that you don't know what to test next or how to face meetings with customers, you can try a more specific way of TDD called Behavior Driven Development. Well, that is my understanding of BDD but I haven't read enough.

Update: (December 12, 2008)
Behavior Driven Development is a step further TDD. BDD is useful when you need to test the behavior of your function. Say that the method you're testing is saving some data into the database in some cases, but it returns "success" for this case and also "success" for the case where it does not need to persist any data. When you write the test for such a case, you can't just assert on the returned value. You've got to ask for the behavior. This is a perfect scenario for BDD. Same happens with access to files in the filesystem. Mock objects are a key tool for BDD as they allow you to test behavior without actual database persistence or files access. You can smell BDD when the thing you need to test goes beyond testing a returned value. Sometimes, I like to call BDD, pseudo-acceptance tests, because to me, they are more than unit tests, but still not acceptance tests. They are getting closer to the actual work flow of the application, they are really useful. I'll post about this in the near future.

The Business of Software

Are you an entrepreneur? Tired of your job? Are you a developer thinking of starting your new software company?
If so, you must read Eric Sink's book: The Business of Software.

I've just finished reading this VERY interesting book oriented to those entrepreneurs like me, that are willing to start a software company. I founded my own company three years ago, but the company wasn't mine altogether, I owned just 25% as we were four partners. So in the first two chapters of the book I've seen myself in some respects during my time at that company. I totally agree with Eric in many things.
The book is focused on Independent Software Vendors (ISV) which means that you have to have a product. I'd say it is actually focused in micro-ISV which means that the company starts with a single person. For those reasons, my ex-company does not match the topic exactly, as we started four and without any particular software product.
Here you go a few points that I learned with my company and you won't read in Eric's book (They are just an excerpt as I'd need a whole chapter to write about the whole experience):

  1. You have two choices when starting a software company:
    a - Develop software products and try to sell them as Eric says
    b - Base your business on services: Support for open source software, custom made software, servers, networking, hardware, etc, etc, etc.

    What I think:Never choose option "b" if there is no market in your place. Your prospective customers will be mainly in the area you work and you won't success if they are not willing to pay for technology/software. Custom made software is more expensive than you might think and it will be really hard (to not say impossible) to get your customers pay off its actual value. At least in small cities in Spain, option "b" is a suicide.
  2. Dont's start with any partner, no matter how good friends you are and of course, never ever work with your wife:
    The reason to have a partner has to be the same than the one to hire somebody. Read the section about "Hiring" in the book. Your need for a partnership has to be even stronger.
    In case you are several partners, make sure everyone has his/her role, and the roles are different. Anarchy does not work on companies. Take a path and follow it till the end, focusing as much as you can. Don't take several paths at the same time. Have every partner absolutely responsible of her liabilities and trust her.
  3. If you work on services, don't spend money in Trade Shows. You have to be there because you have to, (so yes, better you go) but don't spend any money in gifts for people or in a super appealling booth. Invest your money advertising in the Golden Pages and other local publications where people look for service providers.
  4. Even if you use test driven development or any other methodology where you test the software, have a bunch of people in the QA team before releasing any product to the end customer. This might sound obvious but I know many companies that don't have any QA team.

I won't tell you which of these decisions we made at that company, these are just my thoughts, regardless of what we did or we didn't. Maybe in twenty years I'll write a book on all my experiences and experiments and tell the whole storie of my business aventures.

Now, more things about the book. I knew about Eric two years ago when I found his excellent article "Developers Not Programmers". Before moving to Ireland, I sent him an email asking for job and he sent me a friendly answer saying he didn't need developer at the moment. Since that, I've followed his blog at http://software.ericsink.com and I highly recommend his book.
I've learned funny things (sometimes crazy) about the American culture. I appreciate the most, the chapters on marketing and sales. Did you know that Eric worked on Abiword and Internet Explorer from their beginning?
I found very interesting the sections talking about .Net and platforms.
Look at this algorithm at page 137:

Idea FindGoodProductIdea()
ArrayList candidateList = BrainstormLotsOfIdeas();
return ChooseTheBestIdea(candidateList);

Brillian, isn´t it?

I am going to start my own company again, but this time things are going to be much more different. I'll be a micro-ISV and will leverage many ideas from the experience of Eric. Thanks Eric!

Refactoring:Improving the Design of Existing Code

Last book I've finished reading is probably the first one I should have read since I started my software development career: Refactoring is a masterpiece of Martin Fowler with important contributions of Kent Beck and other brilliant architects. In every chapter I asked myself why didn't we study this book in colleague. The book was edited in 2000 but refactoring is not new. I remember arguing with my programming teachers things like, why a method had to have a single end point, things they taught us wrong. As we all know, university is far behind reality and it takes a long time for them to teach new trends so maybe within a decade people will teach refactoring and test driven development in colleague. By the way, here you go a nice article of Joel Spolsky on the Computer Science degree.
Martin Fowler is so far the best writer I've ever read in english. I've learn a lot of english reading his book, it is very expressive and has a nice literary style.
The firsts chapters talk about refactorings that are defined in detail later on so I'd recomend reading the book twice.
Although the book uses Java code, it is perfectly applicable to .Net, and some refactorings let you see some advantages that .Net has over Java, as having object references rather than objects by value.
Some nice sites on refactoring are:

Eladio, I hope you enjoy this book 🙂

Juval Lowy on WCF

I am reading now a very interesting book on WCF. I like the way Juval writes, I learned a lot in his "Programming .Net Components" book so I decided to give this new book a read and I'm enjoying it. But I think what made me go for this book, was mostly the polemic podcast that you can find at ARCast with Ron Jacobs interviewing Juval Lowy. He says that TDD is a "yesterday methodology" among other things. All are arguments for you to use WCF rather than criticism to agile methodologies, or at least that is what I like to think... what do you think?

Now Reading

The two books I am reading now on application frameworks are really exciting and interesting.

  • Developing Application Frameworks in .Net, by Xin Chen
    This book is the perfect sample on how to implement GOF's design patterns over .Net. It gives you implementation examples through the Chen's Simple Application Framework which contains very interesting engines and teachs you on .Net capabilities. I plan to use some parts of the SAF into my Boxerp Framework as the Cache engine for the client side, because I already have a cache at the server side provided by NHibernate second level cache. Im disagree in some points as for instance, the use of SoapSuds in Remoting instead of Interfaces dlls deployment but the most part of the book is awesome. It is very short, you can read it in just one week.
  • Expert C# 2005 Business Objects, by Rockford Lhotka
    This is a 616 pages book plenty of rationale for building frameworks that shows you the implementation of the Rockford's CSLA framework throughout the book and also shows it's use by making sample applications on it.
    It is fantastic to read that seasoned developers as Rockford face the very same issues than you as developing applications or frameworks and also that sometimes there is only one way to get the right solution. But it is more exciting to read a rationale that forces you to change your mind to address the problem in a different manner, or to realize that there are quite a few means of solving a problem. For instance you might design some part of the framework to be used in desktop applications and then realize that you can't leverage that part on a web app. The book may help you on how to write more reusable code among other matters.

What I don't like in either books is that they never quote any open source technology as Mono, MySQL, NHibernate, or Apache, they always quote Microsoft technologies. That is no problem for me because I know that technologies, I know that there is a wonderful .Net multiplatform framework called Mono which is open source, and a wornderful ORM as ActiveRecord but I think the books are not complete for young or junior developers because of this.
You can find out them at Amazon: Here and here

Now Reading

"Now Reading" is a new category in this blog. Sometimes I read interesting books, papers, essays, or just inquiring links and I want to share the information with my visitors. Enjoy this new section.

Well, nowdays Im reading the followin books:

To bring the books from Amazon in US to my house in Spain took 1 month!.
Yes, these books are not new but I think that they are a "must" if you are a .Net/Mono developer. Im focused in several .Net/Mono projects at the moment so this is a good reason to read them.

The next document which is inside Juval's book can be downloaded from:

I was following the guidelines described in it but I wasn't know about it. I will change some Boxerp code to comply with a few Juval guidelines.