Archive for October, 2007
Reading time: 3 – 4 minutes
Podcasts are to real-unabridged-books as a raindrop is to a punch in the face. It takes a team of dozens of people to write a really awesome book. And I find them more satisfying and thought provoking than several short podcasts.
There is nothing so precious as your time. I am only more convinced of this every day.
In the last 3 weeks, I listened to:
- Confessions of an Economic Hitman – even though I don’t agree with his conclusions, it is an excellent memoir. It was personally thought provoking to listen to a man’s entire career life unfold in 5 days on my work commute. Takeaway: life can be very exciting, and some people are very powerful. Move faster, driving for results.
- Banker to the Poor – fantastic book. If you don’t know about microfinance, this is your introductory course. Imagine in your mind what the marriage of finance and social justice would look like. I read it with friends–which led to great conversation–and scheduled a tentative meeting with the great folks at Kiva.org for my friend with an NGO in India.
- Travels of a T-Shirt in a Global Economy – So far it’s entertaining. It is a story telling format asking “where did your T-Shirt come from?” And the government-subsidy-enabled-irony of the cotton planted in Texas, woven and sewn in China, and imported back to Florida.
To effective time.
UPDATE (10/26): Listening to more of the last book tonight. Around the 3h 30min mark, I learn the key driver our present industrial economy: the Spinning Jenny. This was a big deal. One person used to have one spinner to make the yarn. In 1764 they suddenly had eight spinners: a tremendous productivity boost in an under supplied marketplace. By 1800, spinning jenny’s had 80 spinners. And by the 1830’s the price was 1/20th of the 1700’s price.
This breakthrough –mechanized yarn production– propelled the world into the industrial age, and brought consumers into expecting constantly improving technology and quality of life. To me the parallels of present day high tech are remarkable, and the “so what” factor noteworthy.
Two “so what” takeaways:
- The invention of the spinning jenny came because of great bottlenecks in yarn production. In the 1760’s mostly farmers produced cotton yarn, and this was a cottage industry. When harvest time came the families were far too busy harvesting, and weavers had a great difficulties buying yarn. Often they had to walk six miles each day to gather up enough material for that same day’s weaving. This bottleneck –as all bottlenecks– created a great pressure. A pressure that burst forth in invention, and technological revolution.
- In the face of such bottlenecks, Britain sanctioned a contest of which the spinning jenny was an entrant. An example from the past of how using prizes compelled innovation. See the X Prize Foundation for present day contests in medicine, automotive, education, or (Google’s just announced) Lunar X Prize.
Reading time: 4 – 6 minutes
I’m a ThoughtWorker. ThoughtWorks is changing the way that enterprise software is delivered. And with that we take firm stances on heavily debated topics. In previous jobs I’ve tried to push test driven development, unit testing, code coverage metrics, continuous integration… all controversial ‘best practices’. Results were mixed.
A few weeks ago I was at a large web 2.0 social networking site working with selenium grid automation. They were great clients, fully receptive to automated testing. Next week I’ll be heading to another leading internet company to work triage:
- Work on troubled teams whose code is poorly tested
- Enable groups to test legacy code
- Attempt to spread a pervasive test driven mindset.
I’m joining a senior team of ThoughtWorkers and in preparation I’ve thought of various arguments I’ve heard (or used myself) against testing code. I’ll be challenged working with these very experienced people, but I am eagerly looking forward to the experience.
Adding all these tests only makes more code to maintain, debug, and write. This can’t be good – I want less work, not more!
Rebuttal: Would you agree code and requirements often change? Would it be valuable if something could automatically and accurately catch bugs introduced with changes? How about if the original developers are no longer on the project? Testing can enable less work — in a dynamically changing environment. Immediately the work is greater, but over time it is less.
Ok, fair enough, there are some good reasons to do this. BUT, when I want to change something later, I now have two points of failure – the code I’m changing, and all the tests that depend on that code. I haven’t really bought myself all that much security, because if my tests don’t catch the problem well, I’m just as hosed as if I had no tests. Source: first comment from here
- You get better and faster with tests the more you write them.
- By writing tests you further understand the business domain and craft a better thought out solution.
- Whenever making changes in the future you actually have 1 + n points of failure. That which you are changing plus the other interacting systems within the code. By writing tests you will automatically catch the interactions, as well as the initial point of failure. Sure the tests need maintaining, but now with two things to maintain, you catch (almost all) these failure points.
I generally think testing is a good idea. But I’m stressed out, I’ll get to it later… tomorrow I’ll add tests… as soon as I get this working
Rebuttal: Take a page from Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin.. He argues for refactoring but since the two concepts are so tightly entwined, I think the argument applies here:
“Refactoring is like cleaning up the kitchen after dinner. The first time you skip it, you are done with dinner more quickly. But that lack of clean dishes and clear working space makes dinner take longer to prepare the next day. This makes you want to skip cleaning again. Indeed, you can always finish dinner faster today if you skip cleaning, but the mess builds and builds. Eventually you are spending an inordinate amount of time hunting for the right cooking utensils, chiseling the encrusted dried food off of the dishes, and scrubbing them down so that they are suitable to cook with. Dinner takes forever. Skipping the cleanup does not really make dinner go faster.”
Skipping testing does not really make software development faster, because changes are guaranteed. (You’ll have to cook another dinner eventually). Without an easy way to baseline and build upon existing code, time is spent bugfixing that could instead be adding features or writing new tests.
I’m awesome. I don’t write bugs. So I don’t need tests.
Rebuttal: Great. I’m excited to be working with you. I’m sure I’ll be able to learn a great deal. I imagine you like fresh challenges. And in six months or a year this current project won’t be as interesting to you as it is today. In fact, you’ll be on to something more challenging and worthy of your awesomeness.
So that means someone else — possibly a junior developer — will be maintaining and working on this code. Without tests, they will be frequently seeking your assistance and guidance to prevent bugs. This is not what you want, is it? You want new challenges, not constantly being hassled by old code. So write the tests now to ensure your ego and intellect can move forward to bigger and better things.
Elaborating and paraphrasing, Neal Ford argued at eRubycon 2007:
Now I look at not testing as professionally irresponsible. I’m paid to create software, to deliver on a client’s business needs. If I don’t rigorously and automatically ensure I have accomplished this with the minimum amount of bugs — I am committing malpractice.
What arguments have you encountered, and how have you responded?