Things that makes me go hmm

One of my favorit bloggers Eric Lippert wrote recently a post he called “Things that makes you go hmmm”
I’ve written a few hmms in other post bu t just stubled across another one today.
In c# it’s perfectly legal to declare a constructor protected in a sealed class!
Kind of strange. How would you instatiate that class (without using reflection)

Strange things in Reflection.Emit

During my development of ProS I’d had to dig into Reflection.Emit again and one thing that keeps puzzeling me is the way the class in Reflection.Emit is designed.

Take for an example Typebuilder, the corner stone of creating a new class using Reflection.Emit. It inherits from Type however most, if not all methods it inherits from Type is overriden with a version that throws an exception explaining that that particular method is not available on TypeBuilder. The same goes for MethodBuilder, PropertyBuilder and all the other builders That all inherit from xInfo.

The design decision is a hefty violation of the liskov substitution principle (LSP) and for just that reason I’d say they need a really good argument for it. It basically results in yoou having to build a framework for reflection on your newly created types and members to be able to create a compiler. It’s a trivial but time consuming process to make that reflectio possible and well since it’s trivial I can not find that really good argument for violating LSP.

Needless that Im a huge fan of designing by contract, that’s basically my driving motivation for creating ProS, and devolping ProS I hope Im not violating LSP. If I am that is going to give me even more grey hair when I get to testing the plugability. The supporting structure of the plugability is LSP.

Creating dynamic types in .NET

Im working on a language at the moment, which i’ll blog more on later. During the development I came to a point where I needed to actually create assembly files to test the result of the compiler. I’ve writte a few compilers using Reflection.Emit before and I’ve always come to a point where everything seems to be working fine. Using reflection I can see all the methods and all the classes but when I write it to file. There’s absolutely nothing but the manifest.

I seem to forget the trick everytime. If the module name is different from the filename it just wont work. I have actually no clue to why that is. But I had the problem today and with one single change namely making the module name the same as the file name, I solved the problem. If you don’t need to save your assemblies to disk, your basically free to choose the module name.

Don’t believe everything you’re told

One of my collegues had an intereseting error report from our test suit today:

Error: “Expected 3 but was 3″

At first glance it might seem that everything is as expected!! actually it’s not but finding where the error is might be a little tricky. There’s not a lot of information to start with.

The problem is a some what shaky implementation of the unit test framework we’re using. The line of code that reports the error looks like
ASSERT_EQ(++errorCount, errorHandler.Errors.Count);

I personally don’t like the ++errorCount argument but would expect it to be fine except ASSERT_EQ is a macro and the argument is used once for comparison and once for outputting and hence incremented twice

Moral: If you’re not 100% sure what a macro does and you need it to work on a value pass a value. Only pass expressions when the macro needs an expression and not a value.

Changing habits

I’ve been reading a few posts on http://www.hanselman.com/blog/ lately under the category “I suck”. A typical Scott way of putting things and very educational.

It’s so easy to just say every one else are stupid and if they would just listen it would be so much easier and I do it a LOT.

So of that is due to my job requires me to analyse every one else job and find where they can improve. It’s a lot easier to improve what people are doing badly than improving what they are already doing well so I focus a lot of my work on the first but that’s just part of the reason. It’s a lot less costly to find some one elses faults thatn your own or at least so it seems.

I used to work in a company that made different measuring devices and our tag line was “If you can’t measure it, you cant’ improve it” I used to use that a lot a few years ago when I was envolved in pro sport but after retirring from that I’ve kinda forgotten it again. Reading Scott’s post reminded me of the value of measuring yourself once in a while.

Part of my work is changing peoples habits and one of the things I need to improve is the way I communicate what they should do differently. If you take a look at some of my posts you’d see that I’m quit capable of telling people what not to do! that’s seldom a productive way to change habits.

Try saying the following to your kind one day “Don’t put your toast in the VCR” (only works if they actually knows what a VCR is and you actually have one ). The NLP community would call that an embedded command. The visual cortex is not capable of visualizing negations so all the kind will visualize is “put your toast in the VCR” the chances of that visualization helping you reach your goal of no food in the VCR could be improven if you told your kind to eat the toast or asked “how does you toast taste”. After all they can’t answer that if the toast is already in the VCR.

The point is that Im sure I would have more success in changing peoples habits by telling them what to do instead of telling them what not to do.

I personally reacts badly to people telling me what not to do. If my girl friend tells me I spent to much time with my computer and probably end up getting made if she says that to many times. Not because I wouldn’t gladly prioritize her needs. I just hate guessing what they are. If however I got questions like “Wanna go to the movie with me/Sit in the couch and chat” or what ever she would want to do she can’t do because Im working/playing poker at my computer my reaction would probably be a smile and “sure honey”

I might be more extreme in my reactions to being told what not to do. It easily pisses me off but Im sure that Im basically no different from others.

If you want people to do things differently tell them what you want them to do, not what you want them not to do. So instead of telling my self not to tell people what they shouldn’t do I think it’s time I told my self that I should tell people what they need to do.

and as a final note never tell people the should do somthing you want them to do and never say they shouldn’t do something if you really don’t want them to. Say youi would like them to do something. Why? imagine yourself standing in front of an open fridge look at your favorite chocolate cake and a brocolli. You’d probably be thinking I should eat more brocolli that would be so good for me when you look a the brocolli while when you look at the cake you’d think I really shouldn’t have more cake. Im betting you rarely ends up in the couch enjoying a big chunck of brocolli. Usually our “shouldn’t”s are rewarded and our “should”s are followed by punishment. 

Don’tget people to  associate want you what them to do with punishment by saying they should instead use words as “need”, “wish”, “like to” and similar

Wargames in development

Being part of an embedded project team I was originally looking forward to
a lot of complex technical challenges but as time passed I realized, as
often is the case, that the success of a project is a lot more about
people, communication and motivation than about hardcore tech skills and
plain competencies.

To set the scene
The project team I’m part of consists of 18 persons where only a few had
done agile development be-fore they got introduced to in halfway through
this project.

The main feedback the development group is getting and has historically
been getting is from the system test group.

That feedback could in the past be boiled down to “We’ve discovered X new
faults and the following Y faults block our progress” repeated a few times
a week whenever the situation changed.

Over say 14 time boxes where the predominant feedback have been “What
you’ve done is not good enough for us to continue with our system work”
even the most hardcore developers I know would have suffered a blow or two
to their motivation. After all we all want to hear “Good job” once in a
while.

The above description is a bit exaggerated but looking at how people
behave and talk I’d say it’s reasonably close to the essence of how
people feel.

So what I originally thought would be a technically challenging architect
task has turned into a motivational task more than creating UML diagrams
and code structures.
And when it comes to being an architect the way every new idea is
presented needs leave a feeling appreciation and motivation in the
involved developers.

The first of two main focuses we’ve looked at so far is communication
within the project.
The system group now emphasizes how many observations (positive word for
bug) the developers have resolved and the testers have verified and no so
much how many unresolved bugs the system has.

First day they did that even the Head of the department was pleased with
the “progress”. I’ve put progress in quotes since there weren’t any
progress from Friday to Monday but the nonexistent progress was valued
because it was perceived in a different manner.
Knowing that you’ve solved 250 bugs and there’s only 40 known issues just
sound a lot better than “There’s still 40 new/unresolved observations”.

The second one is changing how people think about testing and finding
bugs. At present people fear bugs they are considered feedback of poor
performance and hence people test to prove that the code works (which is a
mathematical impossibility within finite time)

This time box we’re going to have a war game of testing. We’ve got 3
development teams and they are all delivering code 4 days before the end
of the iteration and after that deadline, every group is permitted to
write unit tests and unit integrations test to the code of the other
groups. The group that end up finding the most bugs wins the great prize.
The war game has a few objectives seen from a project perspective.
1. We want to change how people write tests. They should be written to
find bugs not to “prove” that the code works.
By actively rewarding the act of finding bugs we’ll change the focus from
“proving that it works” to “finding what doesn’t”
2. We want the coverage up and since there’s two ways of winning: Either
write a lot of tests finding “all” the bugs yourself or write a lot of
unit tests finding a lot of bugs in everyone elses code we’re sure to get
a higher coverage

As secondary objectives it’s worth mentioning that focusing intensely upon
writing unit test while at the same time being educated in writing unit
test hopefully makes the developers realize which code structures are more
robust than others and finding some of the qualities of testable code.

For me it’s back to holding my thumbs, crossing my limbs and hoping it all
works. Luckily I’ve played the games before so I know they do, and I guess
all there’s left to say is:”Let the games begin”

Single Responsibility

A few days ago I was debating some architectural changes with one of the developers in the team Im currently working in. I had to make it apparent to him what values it would give to our project if we adheared to the single Responsibility Principle.

After giving the theory behind the principle ago we hadn’t really progressed. However he gave me an idea that made it possible to convey the importance of the stated principle.

Imaging we have a class that hold the outside temperature and that same class can communicate via radio with the nearest weather station.

This class is used in an observer pattern, so some where in our application other parts will be updated (I.e the screen reflects the latest changes in temperature)

Our class has three states

valueAccepted
communicating
idle

valueAccepted is set whenever we get a new temperature reading and reverted to idle and the temperature reading is invalidated  by the first read thereafter.

communicating is the state when we are communicating with the weather station.
After testing the first pilot of the code it’s realized that everything works 100% as expected and every one is happy.

So far so good but the class has at least two reasons to change. The communication protocol with the weather station changes or the temperature functionality changes.

To see why this might be a problem let’s change the communicatio protocol slightly. The only change is that every time we sent a command we need to accept a value. This causes one of the developers in our team to sent the object into valueAccepted state.

He thereafter tests that the radio communicatio works again and since the only change had to do with the radio funtionality no one thinks of testing the temperature reading before the new versio is released.

Shortly after it’s realized that the temperature readings are invalid during radio communication.

Had the single responsibility principle not been violated the radio communication would never have been able to alter the temperature flow.

What’s this all about?

I’ve been thinking about blogging for some time now and today turned out to be the day i started doing that.

I was reading this post by Scott Hanselman which is what gave me the idea to the name of my blog.
Since this is going to be the first blog on my behalf I thought way not explain why I named it “Failing fast…” after all most people try not to fail at all.

A few years back I was inline skating a lot trying to make it to the national team only to end up seeing people i had raced (and for a big part of them beated) the entire season. I got angry real angry but I also decided that the year after I had to make it a lot harder not to bring me a long. So I hired a coach to help me with the mental aspects. That turned out to change how I look at tasks in general not just in sports.

On his business card it said “The will to succeed has to be grater than the fear of failing”. Easier said than done but just thinking about that did help and some where down the road I figured out that most of my successes were build on a heap of failures. Or more exactly they were build on what I learned from failing.

Back in the world of skating I had realized that I was holding my self back. I was affraid of what would happen if I was betting everything on one chance to win, I might spent all my energy and wind up last or I might actually win. By not trying I was however ensuring I wouldn’t win. Winning in sport involves gambling, you cannot win on national level with out gambling, no one is that good.

However the more experience you get in gambling the better you will get at it, you will eventually learn when to start your sprint for the finish line, when the try and break away and when just to sit back and let some one else do the work.

Sometimes what seems as the thing not to do might just be what you should be doing. One of my favorite interview replies came from Jacob Piil after winning a stage in The Tour de France. A journalist asked him why he made his break away with 6km (~4miles) to go in a strong head win (that’s usually a very bad idea). The reply was simple “My legs were hurting badly so I thought the others were hurting as well, so they would probably not follow”.

I’m sure somewhere in the back of his mind, a little voice was telling him that it was suicide but having tryed a lot and failed a lot. He knew he’s own body well enough, to know when to change the rules of engagement to succeed.

My point is, that there’s much more information in failing than in succeeding and trying to avoid to fail is as easy to do and as prosperous as trying not to eat. It will hurt and at some point be the end of you.

In the end we all want to succeed but it’s inevitable that we will make errors on the way to success. The faster we fail the sooner we can correct the errors. That realization made me change the way I conduct my work to make errors stand out as fast as possible instead of trying to hide them and as of today that realization has become the basis of the name of my blog.