These last couple of days we have been having a internal TDD course at RemoteX. We had the help of Andreas Brink, whom guided us in testing and over all code quality.
One of the things I noticed during the course is how heavily influenced I was by old habits. We’ve been doing testing for a while, and fallen into the habit of isolating everything using mocks.
One of the things I learned this last week is that mocking is a great tool, but shouldn’t be used as intensely as we have. When pointed out to us we noticed that the way we used mocking actually introduced more code in the tests than we had to.
The order of setting up and doing assertion’s was often distorted since the mocks didn’t have state. Expect calls for example are typically set up in the beginning of the tests, but checked after. Meaning that the verify code is at a different location than the code saying what is verified. End result, the tests aren’t as clear as they could be.
But the influence of habit doesn’t stop there. Details such as how much you use the mouse or keyboard, or utilize the tools available are all depending on your habit for writing code.
For example I have a colleague who knows the keyboard shortcuts, but has the habit of using the mouse. This habit is so heavily indoctrinate that when he is on a laptop, he reaches for the touchpad instead of using the shortcut. The touchpad on my laptop has low sensitivity so the time to write code is heavily hit every time you reach for it.
Hard part is to notice your own habits, some are good, some are bad. Both are good to be aware of.
“I can look at code and understand it but i cant write code”
There seems to be a common misunderstanding that if you can read code and “understand what it does” you understand the code. I’m sorry, If you cant write the code yourself, you do not understand the code.
Being able to read code doesn’t mean you understand it. Anything can hide in those pretty method names.
I went through a business contract, analysing it for weaknesses. I found a not likely case, but still pointed it out.
“You should be a lawyer”, the lawyer says
“I write laws”, I reply.
Now why am I writing this?
Well, there are similarities to developing Laws and developing business systems. Laws are rules in which we humans can work within to achieve value. The value Laws strive for is the value of functional society, a functioning system.
Now developing business software can be viewed in the same way. When developing the software we state the laws in which the users can generate data. The UI is a constraint or law, the business rules are different kinds of laws, and so on. The value we strive for is correct business data, another kind of functioning system.
How it is to live under these governing systems i based on the values they are built upon. A Mac user have different values regarding usability, design, and in some cases “quality” – compared to a Windows user.
Developing software is a team effort. The development team are the legislators of the product they are developing, so which values are governing your software?
Roughly 1½ year ago I produce a plugin for team-system to allow me to report bugs quickly though as I’m working with the code. The idea behind it was from the Fogbugz intoruction video where I think its Joel Spolsky who says something along the lines of “it should take less than 30 seconds to report a bug, else the lazy developer wont do it.”
The resulting plugin was a short-command that started up a UI with a single textbox on it. I wrote the “bug”, and it created an bug item in Team System with my specified title. It also made sure to “record” the context of where I was in the code when I wrote the item. In this case, file and line-number.
In a previous post I discussed how to get things done with teams.
Consider having such a plugin to your IDE that will report the item generated to a central inbox, central for all developers. The item could be a bug, it could also be a suggestion for refactoring, request for more tests, idea for a new feature and much much more.
With such tooling in place, a team could quickly shed some light on issues that aren’t directly related for the delivery of the current iteration. But more related on the values of the team or the ongoing quality of the code product. The issues can be reviewed and managed during a weekly meeting, resulting in product backlog items, sprint backlog items, discussions, meetings. Or just a sense of common values within the team.
I wrote a blog post about how I work with code. The basic idea is that I record actions that I need to take as I work with the code in a format that is readable by the other developers in my team. In case I get run over by a truck they can see where I took off. Also its a way to record what and why I’m doing as I’m progressing through code written by someone else.
I got a response from a former colleague Anna who claimed I wouldn’t need to do it if I had automated tests. Even though Automated tests doesn’t have much to do with personal productivity at first glance, a recording of something that needs to be fixed could be a unit test. If developers run the tests often they are in my shelveset and they can see which pieces of the code I perceive bugs in.
In fact this is exactly what is being done as I work with TDD. Giving support to the fact that TDD can increase the productivity of a developer, following the same ideas presented in Getting Things Done.
Tests however doesn’t record suggestions for design improvements or actions such as “Ask x about icon y”. At Least not as far as I know.
With this concept of quickly creating new tasks and with the GTD and How I work with code ideas. An idea for a new tool popped up in my head.
The tasks that I create based on working code, are cluttered with my own opinions. With the Getting Things Done approach we could have an inbox with Action times created as team members work with the code. In a Weekly review each item in the Inbox could be manage, prioritized, discussed. Some items result in items on a sprint backlog, others simply result in other team members explaining parts of the system to each other.
This weekly review could be conducted outside the normal delivery cycles, as they are partially meta tasks for achieving a common mindset of how and what should be developed. The result could be new features, refactoring, extra testing, reduced bugs etc.
He or she might even know how to say it. It doesn’t mean that a developer will understand.
http://www.giantitp.com/comics/oots0676.html
Communication is everything.
In Getting Things Done, David Allen discusses a work flow of how to handle things you need to-do. Now when I work at a coding task I often find places that could need some refactoring love, or needs to change in some way. There might be potential bugs, violations of DRY and all that.
What I’ve seen so far is that some developers tend to fix these “issues” as they find them, working towards a sort of zero-deficiency or a “if I cant read the code, chances are someone else wont be able to either” motivation.
Working with code in this manner can have some interesting side-effects. To name a few.
- It takes longer to resolve a specific task
- It could result in team conflicts a some developers perceive written code as “theirs”
- It could introduce bugs, if the original intent of the code isn’t captured by tests (not even 100% code coverage will guarantee this).
What I like to do is to finish the task I’m holding as fast as possible. The reason for this is simple; others are relying on it. But while I finish the task I notice these things that needs to be changed, fixed, or clarified. Code items that require attention in someway. What I tend to do instead is to create a new Task to represent this change.
Creating a new task as several benefits.
- It allows delegation and parallel execution of code changes
- It allows the task to be discussed by the team
- It allows me as a developer to finish my current task, without having to fill up my brain with new things to-do
- It allows me to finish the task faster
- It allows the new tasks to be prioritised by the team
- It reduces the chances I need to context switch
- It allows me to work on just one task
Now or the last one I recommend reading Eric Brechners blog post about making your world easier
Eric Brechnerno
I have a good friend whom after university focused on first communication and then management. But now he has turned to development. We’ve been having a few discussion over the past few days about SOLID and REST and Grails. IoC containers and what not.
He hasn’t seen these kinds of concepts in his development so far. But he finds the concepts interesting and he is eager to learn about it. Which has given me a unique opportunity to learn how to communicate these concepts.
Now I’ve been an assistant teacher at the university. But I found that some of the benefits of these concepts are hard to explain, simply because to me their very abstract and I usually don’t discuss them at this level. I’d also like to mention that my friend is great at asking the right questions.
So this is a shout out to Joel. Thanks for teaching me how to communicate these concepts and their benefits.
I recently read Martin Fowlers Bliki entry ComparativeValues. Where he talks about the values listed in the Agile Manifesto. Now Ive given this some thought and there are some things I find interesting.
If you look at it, what he says is that the Agile Manifesto it self is Agile. It was created as a statement to realign how we develop software, and move away from high ceremony project practices. In essence there could, and hopefully it will, where we need too define another manifesto to counter some other harmful development practice. To clarify, I mean hopefully as it would prove that our methods are improving and were Agile enough to adapt to the change.
Another thought which struck me is that making a list of Comparative Values could also be used as self help. Or a means to align your behaviour to a given wish. Create a list of 10 comparative values that describe how you as a person should act or behave. That you can refer to when making though decisions or just reflecting over your day at work.
Or why not create a Comparative Values list just for your team to take care of in team personal issues. How should we behave, what do we as a team value. Have the team develop a list that all members can commit too. That exercise alone should help shed some understanding between team members and could potentially help the team by reducing conflicts.
