Last Friday, October 7, 2011, Henri Sora, “Uncle Bob” Martin (OK, OK, he attended via video, but, nonetheless … ) and I paid a visit to the University of Applied Science, at Hämeenlinna, viz., HAMK, where we gave a talk about “Clean Code”: what it could be, why it matters and, a few tips about how to write some.
Henri presented some basic things about Ambientia: who we are and what we do.
At first, I had the idea that we could watch this video at lunchtime, at some in-house brown bag event chez Ambientia, where we could eat our lunch and, at the same time, discuss the subject informally.
Then, Henri suggested that we could extend an invitation to some students to attend the lunchtime events. We mentioned our idea to some members of the HAMK teaching staff and they got really excited about the suggestion.
I thought that it would be a good thing to talk about code quality to computer science students BEFORE they applied to work for us, before they sent in their applications for employment. Then, they might be in the right mindset from the get go, especially if they were hoping to work for us.
We also had targeted this afternoon as a time to focus on our developers. There was also an idea to get some dialog going between the developers and the HAMK students, aka, prospective Ambientia employees, but sadly we weren’t able to make that happen, to achieve that goal.
Maybe later, if we continue to host these happenings. In my opinion, a friendly, informal group discussion leading to an active exchange of ideas is the hands-down best way for both “sides” to learn new things.
“Clean Code” is neither a new idea, nor is it actually anything special. It’s simply just a way to think and to code, a way for us to perform our work ably.
On our visit to HAMK, our first order of business was to put that simple, elegant concept of Clean Code into some kind of context. We wanted to contextualize the concept. So, Henri described the radical shift in thinking that has occurred among Ambientia developers, viz., a transition from the Waterfall model from 1956 to a conceptualization about software development as craftsmanship. Henri then elaborated on his understanding of software craftsmanship.
Then it was my turn. My main purpose was to alert the attendees about WHY it matters to write clean code. I offered up a couple of key points:
- We coders do not work alone. Usually our code has been read by someone other than ourselves. So code should be “clean” and understandable to all parties. @petercordell has Tweeted: “Treat running code as a side effect of describing your algorithm to a fellow developer.”
- And Craig Larman has observed that “Architecture is a bad metaphor [for coding]. We [developers] don’t construct our software like a building, rather we grow it like a garden.” And yes, developing software is more like gardening than constructing. The better we create our gardens/lay the foundations for our gardens and sow our fields, and the more we take care of what we grow, the easier it will be to harvest and plant new crops, new seedlings. The constructing phase is only just a small part of the whole life cycle of software development.
- Then I asked the developers a rhetorical question: Is it more fun to repair something old or to create something new?
- The last point was an obvious one: MONEY! Customers pay more for new features than they do for bug fixes. And if you develop your skills, you might even get a better salary too… 🙂 I emphasized my point by telling the story about a friend of mine, a good developer, actually the best one on our team, who mainly worked on cleaning up the mistakes that others had made over the course of a whole year. Cheap? I don’t think so.
Then we watched this video. Afterwards, I listed my three — 3 is the number of the day — main ways to attain the goal of Clean Code. You are welcome to learn more about the subject by reading this blog post. But, in short, “just the facts, Ma’am,” remember these 3 pointers: One, Communication, viz., people, code; Two, Testing, viz., TDD or “first think about how to test, then code” and “without passing the test, there is no code” and Three, Refactoring, viz., continuous code improvement and “code is never ready”). Again, Communication, Testing and Refactoring.
After our presentation, we had time for some Q & A. There wasn’t as much talking as I had hoped, but we fielded some good questions and hopefully gave some good answers, too. At least we initiated a two-way dialog between Ambientia and its professional developers, on the one hand, and the HAMK students, on the other. And I hope the exchange, the relationship continues because I believe this kind of interaction benefits both sides tremendously.