Posts Tagged People
How you write code is a habit
Posted by Morten in Uncategorized on December 10, 2009
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.
Understanding code
Posted by Morten in Uncategorized on December 8, 2009
“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.
Is software development too complicated?
Posted by Morten in Uncategorized on November 23, 2009
.Net rocks had a panel discussion a while back, regarding the increasing complexity of software development. A panel discussion they have been refereeing back to a few times in the shows since. In general venting the possibility that all the options available is just adding complexity and might not result in any business value gain.
To contrast this I’m currently listening to the Stanford Entrepreneurial Thought Leader Lecture Series podcast, where they recently had Quincy Jones III and Chamillionaire talk about Successful Independent Promotion: From Artist to Entrepreneur. Where they are excited about how web-development is becoming simpler, and more accessible to “urban” artists.
The contrast is quite interesting between the two pod casts, one talks of adaption and innovation. The other focuses more on consequences of the work of others.
I just realised that a while back was 24 issues of Dot Net Rocks ago, and congratulations to the 500th show of Dot Net Rocks.
Meetings: Focus on Doing
Posted by Morten in Uncategorized on October 27, 2009
My time spent in meetings has been increasing the last couple of weeks. I’m no fan of meetings. One of the reasons I don’t like meetings is that most of the time they are not as productive as they could be.
So last week I had an idea, or rather two, I thought I’d share.
- Some meetings you can almost instantly spot that the participants have different views about what the meeting is about. So start of the meeting by having the participants what they hope the outcome of the meeting would be. This could probably be done as an intervention if you identify this problem.
- A good meeting organizer will summaries at the end of the meeting. A good summary will contain what each participant takes with him or her as action items, to-dos, as a consequence of the meeting. If none of the participants have any action items with them after the meeting, the meeting was most probably waste.
Naturally there are meeting techniques to increase the formality of the meeting, but these shouldn’t be necessary unless you need a formal protocol from the meeting.
I write laws
Posted by Morten in Uncategorized on October 19, 2009
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?
Seven Habits: Exercises for habit 1 and 2
Posted by Morten in Uncategorized on October 6, 2009
In a previous post I described a session where I’m helping a former colleague in her 7 Habits course. I’ll just describe the exercises me and Anna covered.
Homework
Anna had me do some homework. To think of which things affect me, what worries me about them, and which of them I can affect.
Now I went over this at least three times, the most meaningful of them was one was on the subway on my way to work. I combined a list of things that affected me and what had worries and which I could affect. The list is no where near complete, but it served as material for a discussion.
The purpose of this is to know, what I can affect. What my decisions affect and in what way. By knowing this I can decide how I want to act based on knowing what I can affect, and do so before I act.
Positive feedback
I really liked this exercise as I need to conduct analysis of these things on my self.
Anna had me conduct a list of people which I perceive have had a positive impact in my life. Secondly she had me imagine each and one of them on my 60th birthday, giving a speech. Then note the keywords they would use to describe me.
By knowing this I can identify how I want others to perceive me. By knowing how I want other to perceive me I can act accordingly, it helps me identify the goals I wish to achieve.
This helps me with the second habit, Begin with the End in Mind: Principles of Personal Vision.
Negative feedback
It is not enough to know what you want to become, you must also know what you don’t want to become. This is similar to when I write a vision document for a software feature, I describe what I want to solve, but also what I don’t want to solve with this specific feature.
We conducted another list, this time of people whom I dislike. Next, why I dislike them. Most of the time you project negative aspects of yourself onto others. By identifying what you dislike in others, you can identify which aspects you do not want to reflect on your own person.
Here I have a suggestion for making this exercise more efficient, make a root cause analysis of what you dislike about the person. For one person on the list I wrote “mismatch in vision”, but this is most likely caused by something else.Current work goals
Identify the three most important goals you have in your current position, imagine a situation in which these are solved. Now identify what you have to do to get there.
Seven Habits
Posted by Morten in Uncategorized on October 5, 2009
A Former colleague of mine is attending a Seven Habits course. She asked me to help her out with her homework. The concept is that we go through some exercise as she takes on different habits in the course.
Today we met for the first time to discuss this. Basically Anna got to explain the first two habits to me, and we did some exercise. I’ll go through some of my thoughts for the exercise but first I have to take a moment to elaborate on this teaching technique.
I like the strategy that Anna’s coarse is taking. It is a leadership course, and I believe that part of being a good leader is also to be a good teacher. Idea to have participants of the course work with another outside the course serves several purposes.
First we have to admit it serves a market purpose, as Anna goes through the course she will spread the word to people around her who are interested in leadership aspects.
But also this will serve three purposes for Anna. One is the built in reiteration of the course material helping her remember the material they’ve gone through in the course.
The second is that she gets my invaluable input, just kidding. She gets to see discuss the habits with the a fresh pair of eyes. She gets to explain the details, and at some points dive deeper into the details of the the habit under study.
Last but not least, Anna gets to practice pedagogical leadership with someone.
Now I hope I can provide Anna with some good input. I’ll have to put some work in for the second purpose of the exercise, to help Anna get the most out of the course she can. As this is the part that I truly can affect to make sure these exercise produce the most value.
We need more automated tests
Posted by Morten in Uncategorized on September 14, 2009
During the end of the the 20th century, IBM had a TV commercial that I’m quite fond of. I can’t find it on YouTube, but its quite short. There are two suites talking, one reading a magazine. The one with the magazine says “We need to be on the Internet”, the other asks, “Why?” the first replies “It doesn’t say”.
I’ve seen this approach applied to Software quality several times now.
Allot of managers are hearing good things about automated tests. This results in allot of in house improvement projects trying to solve the question “How can we get more automated tests”.
The problem is that the question is asked all wrong. What the question really should be is “How do we improve software quality?”.
The end result might as well be more automated tests. But if you have a team of developers whom have never worked with testing. Your product isn’t going to be testable, and they will need allot of help. Help to set them up, but first and foremost help to understand why it is important to, not test but, to produce High Quality working software.
Most developers do not believe that there is a problem with their quality of the software. Without getting the team to think about software quality while their working, automated testing will take a long time to get in place. Above all the investment on automated tests will have a longer Return of Investment.
Now automated tests might be a part of the end solution for improving the quality of software, but getting the discussion about software quality going in a well behaved manner can have so much more Return of Investment.
Tooling idea for Getting things done with teams
Posted by Morten in Uncategorized on September 11, 2009
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.
How I work with code the unit test part
Posted by Morten in Uncategorized on September 10, 2009
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.