Currently viewing the category:
"Agile"
One of the best books I’ve read about design is Domain Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans. InfoQ has a small ebook called Domain Driven Design Quickly that provides a nice summary of the book. It was a good refresher for me as I read DDD about three years ago.
So What is Domain Driven Design? Read the link to have a good overview. Here are the two most important points:
- Focus on modeling the domain and domain logic of your application.
- Build a “Ubiquitous Language” that is used by all the team (from domain experts to analysts to developpers).
The most interesting part of the book for me was the patterns presented as the basic building blocks of a model-driven design: Layered Architecture, Entities, Value Objects, Services, Modules, Aggregates, Factories, Repositories. These are all very simple but fundamental patterns in software development. These are types of objects that are present in all designs. Understanding the difference between a value object and an entity is crucial and can help simplify a design.
The book also discusses the importance of iterative design, the importance of incorporating back what you learned about the domain in the model as you iterate and how to preserve the integrity of the model. There is a good discussion of ways of separating the model as the team gets bigger.
The value of this book for a Rails developer
Ever heard about skinny controller, fat model? This is THE book about building a rich model.
However, it really depends on the type of application you’re building. Most Rails application are mostly concerned about CRUD operations without too much logic behind. You won’t get out much from this book.
But if you’re working on a business app with a lot of business logic, then this is a must-read.
The ebook also has a small interview with the author. He highlights the expressiveness of ruby and mentions that DSLs are probably the next big step in Domain Driven Design.
Popularity: 33% [?]
The Rails Edge: Quotes and Notes is a very interesting collection of quotes from the rails edge conference. Two in particular caught my attention:
“Metaprogramming + DSLs is the Ruby equivalent of Design Patterns in the Java world”
— Chad Fowler. Fowler’s point here was more about the buzz and hype, just like there was a time in the early 2000s when every Java programmer wanted Design Patterns whether or not they were needed, Fowler sees a similar rush to add DSLs to Ruby programs.
“If programmers, on average, were able to write parsers and compilers, Ruby on Rails would not have taken off”
— Stuart Halloway
This is something I’ve noticed a lot recently: every plugin that gets released is a DSL! or it uses a cool metaprogramming trick! That’s nice, but was it really needed? And can we really talk about a ‘language’ when your plugin adds two simple commands to a controller?
I guess it’s a rite passage when learning ruby to write something using metaprogramming. The problem is when you start using it for everything, just like when you add patterns after patterns to your code, just because.
Again, this is a case of using the right tool for the right job. Metaprogramming is a power tool that is useful some time.
Here are other quotes that I like, as they echo the discussion I had with Fred Brunel at the last book club about process:
“The right process is always ‘not quite enough process’”
— Stuart Halloway
“Do the dumbest, simplest thing that almost works”
— Stuart Halloway, on process
“The traditional view, with sixteen pounds of documentation, introduces a single point of failure in the process, understanding the problem domain”
— Dave Thomas
“Getting a specification involves bullying the customer”
— Dave Thomas
Popularity: 15% [?]
On thursday, I also attended a presentation on “Software Testing as a Social Science” by Cem Kaner, from the Florida Institute of Technology. It wasn’t bad, but he spent so much time with traditional definitions of testing that he barely had time to scratch the surface of the social aspects of testing, and missed an opportunity to come up with something really interesting.
Friday morning I went to a talk on an agile experience at Motorola, a CMM level 5 organization. Unfortunately, I did not have time to ask what obstacles this posed to the implementation of an agile process. Things however seemed to go pretty good. The second release delivered the same number of new features in half the time with half the people as the the first release that was only using an incremental style of development, but otherwise the same practices as traditional waterfall inside Motorola. The speaker gave cautions on a lack of documentation to help new members get up to speed (I would have thought that pair programming would help here). He also mentioned that automating tests can be very time consuming, which is something that I’ve experienced myself.
The next keynote was by Peter Grogono, from Concordia University, about modular concurrency. His plan was to show that OOP has problems and that something better is needed. He of course showed trivial examples in Java to prove that you can do stupid stuff. Duh. So OOP is bad because Java made some stupid choices, especially when it comes to concurrency. Things got more interesting here as he mentioned research that was done in the seventies that offered much better and safer concurrency than Java does today. He quickly showed an example of what he is developing, something that uses “cells” to separate modules. However, his example was the traditional hello world that took 20 lines of bizarre redundant setup. But there was an interesting concept here where the deployment of the code, meaning where it will run, what process, can be changed separately from the the actual program because of the way the language is designed. If I understood correctly, that means you could write the program without worrying too much about concurrency (but still making things modular) and it would be easy afterwards to scale or parrallelize the execution of the program across machines. This talk would have been very cool if Dr. Grogono had skipped the useless and pointless OOP (Java) bashing.
Popularity: 10% [?]
But the best technique I know is to use iterations (2-4 week long iterations). That way, you can release virtually at any time. You know that the contents of each iteration works. You know you’ve implemented the most important requirements first. And it’s ok if management wants to release — because the product is ready.
There. I couldn’t say it better myself. Stop wasting everybody’s time and start iterating.
Popularity: 5% [?]
This principle comes with a important consequence – that it’s important that programmers put in the effort to make sure that this code is clear and readable.
I’m quite a fan of XP and agile in general. There’s a common misconception about documentation as related to XP, meaning that XP prescribes not to write any documentation. In a way it’s almost true, but it was just to question the value of all the documents that some process require. When you really think about it, an awful lot of them won’t make the final product any better, nobody will really want to read them, and they will probably be out of date.
Which is why I really like this quote from Martin Fowler. It added one more element to why I think why the XP practices, when well understood, lead to a good program, with good code and good design. I strongly suggest you read the whole article.
Popularity: 8% [?]
I discovered that in the presence of SelfTestingCode, most bugs that static types would have were found just as easily by the tests.
Last night I was playing with rails trying to understand some of the features. Old habits kicked in. I did not write some tests and got bitten once again. Lost almost an hour on a few stupid typos. As Martin Fowler explains, tests are more important in a dynamic typed language as the compiler won’t catch some errors for you. Fortunately, rails supports testing right out of the box.
Popularity: 9% [?]
I don’t care how good you think your design is. If I can’t walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you’re paying a price for it.
In the last few months I’ve had the chance to code a couple of projects using test driven development, that is writing unit test before the actual code. Whenever I have to go back to code not written that way, I’m entering a world of pain. The peace of mind it provides when writing and most importantly changing code is unbelievable.
Because you want the test to be easy to write, you have to make sure the class is easy to instantiate. This generally leads to very low coupling, which is a sign of a good design.
Popularity: 7% [?]
