An interesting blog post about Mockito (and other mocking frameworks)
I've recently joined the mockito google group and this link was posted recently.
http://rrees.wordpress.com/2009/04/12/three-little-mockers
It mainly compares Mockito and JMock and how the author thinks that Mockito encourages developers to be lazy and allows classes to grow fatter in terms of functionality and collaborators. The author also thinks that Mockito encourages Test Driven *Development, while JMock encourages Test Driven *Design. Don't forget to read the comments too, that's where the drama's at.
What do you think? I haven't used JMock, so I can't speak myself. But to those who have, does JMock compel better code design because it increases the amount of noise in the code? Do you think there's a difference between Test Driven *Development and *Design?
Another interesting note is that there was a ThoughtWorks team in the same location as the author, and they were pushing for Mockito 
Book review: Clean Code: A Handbook of Agile Software Craftmanship
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
My friend and colleague, Mark, lent me this book about 9 months ago and I've been slowly reading (ok, i've been slacking off for a few months) through it but I've finally made it to the end (well, sort of the end). I've been learning a lot of the things that were mentioned in the book over the course of the past few years working with my talented colleagues at ThoughtWorks but I think Uncle Bob (and friends) did a very good job of nailing down the practices that help developers write clean code. The book uses a lot of examples and shows a lot of code as well. I would recommend it for any developer who would want to improve themselves and learn how to write better and cleaner code.
What I learned
What is Clean Code? Uncle Bob asked some very well-known and experienced programmers what they thought and almost all of them agree that clean code should be straightforward, easily understandable and does ONE thing well.
Meaningful Names
The first step towards straightforward code is to have names that clearly reveal the intention of the author. That includes variable, method and class names. A name should answer all the big questions: why it exists, what it does, and how it is used. For example:
int d; // elapse time in days
The name d reveals nothing. We should choose a name that explicitly says what it represents:
int elapsedTimeInDays;
Functions
Functions should be small. They should do one thing. They should do it well. They should do it only.
In order to make sure our functions are doing only one thing, we need to make sure that the statements within our function are at the same level of abstraction.
The ideal number of arguments for a function is zero but one or two are acceptable. Three arguments should be avoided where possible, and more than three should require a very special justification else shouldn't be used at all. Passing a boolean into a function is a bad practice. It immediately says that the function is doing more than one thing because if the flag is true, it does one thing, if it's false, it does another.
Error handling should be done separately, because that's already doing ONE thing.
Comments
I have always hated code inlined with comments (after of course I learned that my code should serve as the one and only documentation). It complicates the code because one would have to read the code AND the comments and if they don't match up then it will cause more confusion.
Objects and Data Structures
This was an interesting chapter that outlined the difference between the two entities, which I thought were interchangeable. Objects hide their data behind abstractions and expose functions that operate on that data. Data structures expose their data and have no meaningful functions. They basically are virtual opposites.
This also highlights the differences between procedural and OO code.
Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.
This is not to say that we never want to have data structures, but I think we just need to be careful when creating our "objects" and make sure that they aren't data structures in sheep's clothing.
Error Handling
I've been learning more about this topic recently, especially in one of my previous projects where error handling was of utmost importance since we were writing a shared services tool. It's important to know when to throw exceptions and how to catch and handle them properly. Here are a few pointers from Michael Feathers:
- Use exceptions rather than return codes
- Write your try-catch-finally statement first
- Use unchecked exceptions
- Provide context with exceptions - to determine the source & location of an error
- Define exception classes in terms of a caller's needs
- Don't return null
- Don't pass null
Unit Tests
If there could only be one important thing to software development, testing would be it. But sadly a lot of developers treat tests as an after-thought, but really when we're manually firing up the application and clicking a bunch of buttons to see if something was working, we could automate those steps and voila! we have a test!
The next step would be to drive the code from the test. The Three Laws of TDD (Test Driven Development):
- You may not write production code until you have written a failing unit test.
- You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
- You may not write more production code than is sufficient to pass the currently failing test.
Classes
I wrote a post about this chapter previously. You can read it here.
Systems
To stay clean a a higher level of abstraction, we need to be able to separate the construction of a system to it's usage. There are a few ways that we can achieve that, the most primitive being moving all aspects of construction to the main method. Other ways include using factories and dependency injection.
Chapter 17 lists the code smells and heuristics that Uncle Bob has encountered over the years.
All in all a very useful book!
What makes you Agile? Help complete a survey to find out!
I recently wrote a post about whether or not we are practicing Agile the right way and what are the practices we have forgotten about or consciously left out because they made us feel uncomfortable.
Jurgen Appelo is running a survey that might give us an idea which practices are really "Agile", and which Agile practices are really important and which ones are actually applied on how many projects. Please help out by participating! Jurgen's survey is the first that doesn't focus on coarse-grained methods like Scrum or XP but rather on 66 fine-grained individual practices.
Book review: Predictably Irrational: The Hidden Forces that Shape our Decisions – Part II
Predictably Irrational: The Hidden Forces That Shape Our Decisions by Dan Ariely
The High Price of Ownership
Why do things become more valuable after we own them? Why do we think that the 10 year-old couch that we are trying to sell is worth $200 when someone else wouldn't pay more than $30 for it? I won't be able to phrase it more aptly than Dan does:
Ownership pervades our lives and, in a strange way, shapes many of the things we do. Adam Smith wrote, "Every man [and woman] ... lives by exchanging, or becomes in some measure a merchant, and the society itself grows to be what is properly a commercial society." That's an awesome thought. Much of our life story can be told by describing the ebb and flow of our particular possessions - what we get and what we give up.
The 3 irrational quirks in our human nature:
- We fall in love with what we already have.
- We focus on what we may lose, rather than what we may gain. Our aversion of loss is a strong emotion.
- We assume other people will see the transaction from the same perspective as we do.
Keeping Doors Open
Now this plagues me personally more than anything else. I've been finding it hard to put my roots down but I feel as though I would be missing out on life if I did. FOMO - Fear of Missing Out.
What is it about options that is so difficult for us? Why do we feel compelled to keep as many doors open as possible, even at great expense? Why can't we simply commit ourselves?
Wouldn't it be nice to have a built-in alarm, to warn us when the doors are closing on our most important options?
Dan suggests that we need to start closing the doors ourselves. Start with smaller doors, then move on to bigger ones.
But the bigger doors (or those that seem bigger) are harder to close. Doors that just might lead to a new career or to a better job might be hard to close. Doors that are tied to our dreams are also hard to close. So are relationships with certain people - even if they seem to be going nowhere.
I'm leaving out the last 5 chapters because there's just too much I want to point out. But you should pick up this book, for yourself, or for a friend. It points out a lot of things about the human nature that we take for granted but if we start noticing them we might be able to make our lives a little easier, a little less complicated, possibly a little better.
Delivering business value
What do we mean when we say that we are delivering business value for our client? What do our clients get at the end of the day after forking out a huge amount of money? A piece of software? A piece of software that works? A piece of software that works and does what the client wants it to do? A piece of software that works and does what the client wants it to do and brings their business to the next level?
How far are we pushing the lines that define these two words, Business Value?
I've had many discussions with my colleagues about this particular topic and it's always an interesting conversation.
When on a project and there is really nothing to do, do we sit there and create work for ourselves so that we keep billing the client for that time even though we're not really delivering any value? Or do we alert the client that work is running low and that we should possibly think about restructuring the team or taking a closer look at the project?
At the pub yesterday, I was fortunate enough to meet the great Dan North, author of BDD and all around an old-school ThoughtWorker and he puts it like this (or at least the bits that I remember).
Suppose your client wants to build a triangle.
And the following things are what's need for the triangle to be completed.
And each of those have sub-requirements and so on and so forth. Developers are usually focused on the minor detail, the day-to-day implementations, the nitty-gritty and sometimes forget the big picture and why the team was working on this particular functionality in the first place. Then someone decides to take a bird's eye view of what the team is currently doing and voila, we find that Part C of the system is actually redundant and we could deliver the product in less time and money than what was planned.
So now comes the question. What do we do? Do we approach the client with what we just found out and possibly end the project earlier, or take some people out earlier? Or do we just keep billing like nothing happened and maybe finish a day or two earlier just to look good?
What do you think are actions that define business value and what aren't?
Are we walking the Agile talk?
I recently watched this video of Uncle Bob. He asks the hard question, why are we still talking about XP (or Scrum or Agile for that matter) after 10 years? There are many organizations that claim to practice Agile and claim to be experts on it but there is always something (or a few things) missing and they continuously run into problems like painful deployments, constant broken builds, features not making releases on time, miscommunication between stakeholders and developers, etc. Issues like these are common to software development teams but Agile is supposed to help solve some of them.
So what are we missing? What are we not doing right?
In a recent conversation with a colleague, I posed these three questions.
- What have you experienced to be a project's biggest pains?
- lack of communication
- broken software being deployed
- dependency of 3rd party components in the build
- long meetings to define and discuss stuff instead of just trying them out and seeing what happens
- upfront analysis and having to redo it later - Do you think those teams of yours were practicing Agile right?
No - Do you think that practicing Agile right would help with the pain points you have experienced?
I think we should cut the the meetings and try the set based concurrent engineering approach of lean, i.e. more prototyping. We need more people to care about the quality of what we produce. We should analyze as we need to, not up front. That would make the project more fun for people, more like they are producing something worthwhile. Colocated teams would improve a lot of things.
What are the things we should be doing to make sure that we're practicing Agile properly? My colleague, Liz Keogh, recently wrote a post entitled What does "Not Agile" look like? and exhorts us to examine if we're actually doing Agile justice. I think we've arrived to a point where we have talked about Agile enough and should actually be doing it right.
In Uncle Bob's video, he points out a few things, and I paraphrase:
XP did not set out to conquer the business world, it set out to make it easier for a small team of programmers to do a good job. So what got left behind? The technical aspect of Agile. Scrum focuses on features, we have to go through the backlog, feature after feature, banging it all out, architecture and design doesn't get attention. XP however is all about architecture and design. We improve on them iteration after iteration.
Who here has been significantly impeded by bad code? So why did you write it?
The only way you can get done on time is to refuse the mess. You want to go fast? Don't rush. Seeming fast is not being fast. We are often seduced by the seeming fast. Refactoring is the act of changing the structure of a piece of code without changing its functionality. It shouldn't be something we put on the schedule, we should be constantly doing it.
In this other video, Robin Dymond talks about how Lean helps to take Agile to the 'next level' and why organizations that fail to change will not have successful Agile teams. He also believes that organizations will need to reorganize around teams to get the most our of Agile.
Just hot off the press, my colleague Mark's views on Lean and organizing teams for better efficiency.
I think that Agile is about weeding out the practices that don't work and replacing them with ones that do. It's all about embracing change and working towards a perfect software development environment, however far-fetched that might be. I think we should still try.
Book review: Predictably Irrational: The Hidden Forces that Shape Our Decisions – Part I
Predictably Irrational: The Hidden Forces That Shape Our Decisions by Dan Ariely
I had run out of good, engaging books to read until a dear friend of mine, Sonia, gave me this as a gift.
Semi-paraphrase from the book:
Standard economics assume that humans are rational beings; that we have all the information about our decisions, and we are able to discern the value of the different options that are before us and consequently able to weigh the pros and cons of each option before making our decision. Even if we were to make a wrong decision, standard economics suggests that we learn from our mistakes very quickly on our own or with the help of "market forces". This is how conclusions are drawn about everything from shopping trends to law to public policy.
Interesting? Read on.
What I learned.
Everything is relative
Life sometimes involves a lot of comparison. We compare who has the biggest pencil case when we're in elementary school. We compare grades when exam results are out. We compare which family goes for the coolest vacations. We compare colleges to decide where we want to spend the next 4 (or 3 or 5) years of our lives. We compare student reviews of Advanced Graph Theory and Computer Graphics I to decide which class to take for our senior year. We compare job benefits when we graduate to decide how our career would start out. We compare looks, family background, job and car of the two guys who have been calling us to know which one to give a cold shoulder to when they call again. But as it turns out, everything is relative. It becomes a problem when we look at our decisions in a relative way and compare them locally to the available alternative.
One way to curb this problem is to control the "circles" around us, moving towards smaller circles that boost our relative happiness. Author Dan Ariely suggest this: if we are thinking of buying a new house, we can be selective about the open houses that we go to, skipping the ones that are beyond our means. If we're thinking of buying a new car, we can focus on the models we can afford, and so on.
Another trick is to take a broader perspective on things, which is not always easy. Consider this example, you need to buy a new pen and a new suit. You go the nearest office supply store and see that the pen that you want is $25, you almost buy it when you see a flyer for the same pen that's sold in a store 15 minutes away for only $18. Would you spend 15 mins of your time to save $7? Most people would.
While shopping for your suit, you find a nice one for $445. But a guy who was browsing next to you whispered that another store is selling the same suit for $438, but that store is a 15 minute walk away. Would you make the trip to save that $7? Most people wouldn't.
What's going on here? It should be irrelevant if you were saving $7 on a $25 purchase or a $445 purchase, after all, it's still the same $7.
The Fallacy of Supply and Demand
Arbitrary Coherence is the idea that although initial prices are "arbitrary", once those prices are established in our minds they will shape not only present prices but also future prices (this makes them "coherent").
Price tags themselves are not necessarily anchors. They becomes anchors when we contemplate buying that product or service at that particular price. We are influenced by anchoring in every choice that we make, whether or not to buy a certain blend of coffee, whether or not to go to that jazz concert, whether or not to live in the suburbs, whether or to vote Republican, etc. Standard economic theory says that we make these decisions based on our personal preferences, our likes and dislikes. But could it be that our lives are so carefully crafted in such a way that we are just a product of Arbitrary Coherence?
In a similar manner, claims of free market and free trade don't really make sense if our choices are affected by random initial anchors.
The Cost of Zero Cost
If I set up a table on the street and sell you 2 kinds of chocolates: Lindt chocolate truffles for 15 cents, and Hershey kisses for 1 cent, which would you pick? If I were to change the prices to 14 cents for the Lindt truffles and give away the Hershey kisses for free, which one would you pick now? The only caveat in both cases being that you are only allowed to choose ONE piece of chocolate. The power of FREE! is amazingly strong.
The Cost of Social Norms
This is by far my favorite chapter of the book.
We live in a world governed by 2 sets of norms, social and market. The social norms include the favors we do for our friends/family and the people around us. Can you help me move my couch? Can you take the mail in for me? Can you pick up my kids from school tomorrow? These are driven by our need for community and instant payback is not required. Market norms are defined by sharp-edges exchanges: rent, buy/sell, wages, interest, etc. What happens when these two worlds collide?
You are at your mother-in-law's for Thanksgiving and she has just made an incredible spread for the family, complete with turkey, gravy, stuffing, cranberry sauce, green bean casserole and cherry cobbler for dessert. You feel extremely stuffed and slowly sit up from your comfortable armchair, reach into your back pocket and pull out your wallet. "Mom, for all the love that you put into this, how much do I owe you? Would $300 be enough? How about $400?". Imagine the after-math of that question.
The Influence of Arousal
Would we be inclined to do the things we say we will never do when we are in an impassioned state than when in dispassionate circumstances? Do we throw logic and rationale out the window when we are emotionally or mentally aroused (angry, frustrated, hungry, annoyed, etc)? The answer, scarily, is yes.
The Problem of Procrastination and Self-Control
25 years ago, double digit savings rates were the norm in America. In 1994, the number was 5%. By 2006, it had fallen below 0 to -1%! Europeans do a lot better, they save an average of 20%, Japanese save an average of 25%. In China the rate is 30%. What's going on with America?
One problem is that Americans have succumbed to rampant consumerism. But the other explanation is procrastination. The promises to save, to exercise and watch our diet all go up in flames when we see a new car, new bike, new pair of shoes, a delicious looking slice of chocolate cake, or that strawberry milkshake.
Not everyone understands their tendency to procrastinate, and even those who recognize their tendency to procrastinate may not understand their problem completely. People may set deadlines for themselves but not necessarily deadlines that are best for getting the best performance.
To be continued...
What about the small picture?
I saw this IBM ad at a bus stop today with the tag line, "Let's build smarter traffic" (or something along those lines).
My train of thought went along these similar lines: "Hrm, that convoluted picture looks like the software that IBM churns out, i.e. Notes! Too often people are too caught up in the big picture, the architecture, the design, the little boxes and pictures on a piece of paper that represent a system but forget about the lines of code that the system is made of. If we dissect a millimeter of your system, would it still look like convoluted spaghetti code?"
When we are programming, do we follow the practices that make our code clean? i.e. meaningful naming for classes, methods and variables, small and testable classes, good error-handling, etc. I think these practices should be given as much attention as the elements of the bigger picture.
Making teamwork work
I've had the privilege of being a part of many software development teams in the past 2.5 years. Part of the perks of being a consultant is that one gets the experience of being in different companies, environments, cultures, initiatives and goals. Not that I'm claiming to be an expert on how things should work, but it does help to be able to gain different perspectives in a short period of time. Here's what I think is important for teams to pay attention to, but by all means, I don't mean for these to be silver bullets, just observations.
Collective Ownership
Of everything. Of defects, of the broken build, of code refactoring, of talking to the stakeholders. Some think it's a good idea to have specialized teams that drive innovation or improvements, but I think it's the team that feels the pain of a certain problem, be it a terribly long build, or incredibly flaky tests, should be the ones that drive those improvements. They know what the problems are and will have a better idea of how to make things better. Getting an external opinion is a good thing but the responsibility of the "fixing" should belong to the team.
When something goes wrong (i.e. build breaks), we should adopt the "we should fix it" not the "it's somebody else' test, they'll fix it" attitude. Even if it wasn't my checkin that broke the build, if I can be of help, or if I know how to fix it, there's no point in waiting around and leaving the light red.
One backlog, one team. Split backlogs, split teams.
I've learned that it's really hard for a backlog to be shared across split teams that don't have visibility of the big picture and don't communicate across those imaginary-team-walls. Consider this scenario, Company Z has 3 software development teams working on their online website. The teams are seated separately, don't have much communication between them except through email, and a lot of email.
Iteration 1: Team A is given work for Feature Foo. Team B is given work for Feature Bar. And Team C is given work for Feature Baz.
Iteration 2: Team A is given some work for Feature Bar, and some for Feature Baz. Team B is given some work for Feature Foo and some for Feature Baz. Team C is working on another completely different feature. But in the previous iteration, they have identified a few issues for Feature Foo that they would like to fix but since they can't work on Feature Foo anymore, the work goes to Team B who has little to no context of what the problems were.
I think if we want to have a shared backlog and have everyone on the team familiar with the different facets of the work, we need to be ONE team and not multiple teams.
Colocation
Following the previous observation, a team has to feel like they are a team and one way to encourage that feeling is to sit the team together. It might seem like a trivial act, but it does help if it's easy for me to walk up and approach another developer instead of having to walk across the entire floor and feel like intruding another team's space. It's all about false perceptions, and it'll do us good to get rid of as many of them as possible.
Contact Me
Archives
- January 2012 (2)
- December 2011 (1)
- October 2011 (1)
- August 2011 (3)
- June 2011 (2)
- March 2011 (1)
- February 2011 (1)
- November 2010 (3)
- September 2010 (1)
- August 2010 (1)
- July 2010 (2)
- June 2010 (1)
- May 2010 (2)
- April 2010 (2)
- March 2010 (4)
- February 2010 (1)
- November 2009 (5)
- October 2009 (4)
- September 2009 (2)
- August 2009 (3)
- July 2009 (2)
- May 2009 (4)
- April 2009 (9)
- March 2009 (1)
- February 2009 (5)
- January 2009 (4)
- December 2008 (6)
- November 2008 (5)
- October 2008 (3)
- September 2008 (1)
- August 2008 (1)
Categories
- .net (3)
- active record (1)
- agile (9)
- band (1)
- books (13)
- c# (3)
- clojure (2)
- coding (2)
- coding practices (8)
- conferences (1)
- consulting (3)
- continuous intergration (2)
- error handling (1)
- flex (3)
- functional programming (2)
- git (1)
- grails (2)
- hibernate (1)
- integration (2)
- java (2)
- lean (2)
- logging (1)
- mocking (1)
- music (1)
- oop (1)
- osx (2)
- pairing (6)
- philosophy (2)
- photography (1)
- rails (1)
- ramble (10)
- ruby (2)
- Sydney (3)
- tdd (2)
- teamwork (5)
- testing (17)
- ThoughtWorks (19)
- twu (2)
- UI (3)
- web (1)