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
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 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 😉
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.
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):
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:
ArrayList candidateList = BrainstormLotsOfIdeas();
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!
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
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?
The two books I am reading now on application frameworks are really exciting and interesting.
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" 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.