Archives

bookmark_borderHow stackoverflow helps me to solve problems, without posting questions…

Posted on by stefanhendriks

I really love stackoverflow. It brings developers, good ones, together. And because of the community active there, many questions I had where answered.

However, I dare to say half of my questions where answered by not posting any question…

The reason why? Its simple. In order to get the answer you seek, you need to specify the problem precisely. Just posting “it does not work” with some vague description is not enough. It really helps to tell how you stepped through the problem, post snippets of code and so forth. If you are able to specify your problem like that, chances are high (at least with me) that the solution comes along with it. A so called “aha” moment. To me it is like Rubber Ducking. By the time you are half-way through writing down the exact problem you probably figured out the problem yourself.

The good news:

  • You probably found 9 out of 10 ‘doh ofcourse its so obvious’ issues. Preventing you to post ‘stupid’ questions…
  • You end up posting really hard questions (making you look so smart).

The better news:

  • There are people out there who are even smarter than you! And make you smarter in return!
  • You do not have to talk to a real rubber duck at your desk, just type your question at stackoverflow. (your co-workers will stop worrying about your mental state, talking to that duck all the time).

Its a win win win!

In other words…

Answer answer = null;
try {
Question question = formulateQuestionPrecisely();
answer = stackOverFlowService.postQuestionAndGetAnswer(question);
} catch (AhaMomentException ame) {
// never mind, found the solution myself!
answer = ame.getAnswer();
}

Thanks stackoverflow!

(don’t forget to credit those who give the best answers.. it’s highly appreciated)

Now I just read that posting your question, while you know the answer already, is a good thing. So the next time… consider that (but make sure your question has not been asked for already :)).

bookmark_borderThe ten commandments of egoless programming

Posted on by stefanhendriks

Ever heard of the ten commendments of egoless programming? I came accross them a while ago. I just thought of putting them here for history sake, these ten are actually quite good and should be cached on every search engine’s server as many times as possible.

I really like nr 6 a lot. How about you?

So, here a recite:

1. Understand and accept that you will make mistakes.
The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.

2. You are not your code.
Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.

3. No matter how much “karate” you know, someone else will always know more.
Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.

4. Don’t rewrite code without consultation.
There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

5. Treat people who know less than you with respect, deference, and patience.
Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.

6. The only constant in the world is change.
Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.

7. The only true authority stems from knowledge, not from position.
Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.

8. Fight for what you believe, but gracefully accept defeat.
Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.

9. Don’t be “the guy in the room.”
Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.

10. Critique code instead of people—be kind to the coder, not to the code.
As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

bookmark_borderSlick java library and 64 bit

Posted on by stefanhendriks

Note: This post offers a Windows JAR/DLL package. I have delivered a newer version, also for Linux/Mac OS X. Get them from here

A long while ago I played around with Slick. A game library for Java. It offers easy 2d graphics drawing with the speed of OpenGL (by using LJWGL). It has much more features than that as well. 

When I tried it I was running Win XP 32 bit. However, recently I was trying my code again, this time on Windows 7 64 bit, and I encountered the following error:

lwjgl.dll: Can’t load IA 32-bit .dll on a AMD 64-bit platform

I could not find a decent solution easily, but I fixed it by doing this:
– Get the latest source of Slick
– Download the latest LJWGL version
– Use the latest LJWGL JAR and DLL files and put them into the latest source code of Slick
– Run “ant dist” of Slick

Use the newly generated JAR of Slick and the new DLL files of LJWGL together, and you’re all set for 32 AND 64 bit!

If you just want to download everything (DLL and JAR’s), I’ve made a little archive for Windows users. It is unofficial though, no support given!. Grab it from here.

bookmark_borderThe ‘unit’ in unit testing; and kinds of unit tests.

Posted on by stefanhendriks

Recently I had the oppertunity to explain some students about what unit testing was. I started off with the question of “What does unit testing mean?”. They gave different types of answers. One of them talked about the smallest piece of code. And even though he is ‘right’. I asked him to apply this knowledge to his current code where he said “But I don’t want to test my get/set methods, that is useless!”. And so, our definition of ‘unit testing’ became unclear again.

So what is a unit test? According to this article on wikipedia “A unit is the smallest testable part of an application”. But what does that mean? What is the ‘smallest testable part’? Do you need to test get/set methods? Do you need to test assigning values? Yes and no.

Even though the smallest testable part is related to lines of code, I believe it also is related to behavior. I think a better description for unit testing would be to test the smallest piece of behavior of an application. Most of the time you probably will be testing very little pieces of code with it. As long as there is some behavior (context) you want to test.

So do get/set methods fall into this category? Depends… Get/Set methods in themselves are, without context, useless. Returning a value or setting a value is not much worth of testing. However, if you test a method that calls a get/set method and does something with it, that is another story. When code is executed within a certain context, it is perfectly valid to unit test it. An example: getTotalPrice that just returns a value “price” is not worth to be testing. A getTotalPrice that does some calculation is a good candidate to test!

With software development, it is the expected behavior of the software that matters. I compare this with designing interfaces (seperating what and how), where you’re busy thinking what you would expect from a certain object when using it. The behavior of the software; how it presents itself and how the user can interact with it (the how), is different from how the software realizes this behavior (the what). When thinking in terms of behavior when writing code, we force ourselves to think of what the software should be doing, and not *how* it should be coded to do that. Test Driven Development is a way of forcing you to write code that has a good design. It clearly a functional (behavior) point of view.

With that said, a unit test should aim to test the smallest possible piece of behavior. When a total price is shown. There are a few steps taken before it is shown on the screen. One of the important behaviors is that the totalprice is calculated somewhere. Testing the calculation of the totalprice is a unit test. This is a State based test. (Does the class give expected output X when using input Y?)

The totalPrice is calculated from certain input. The output is shown on the screen.
A controller class is putting input and output together, making sure the totalPrice is being calculated and pushed to the view. Making sure that the controller uses its collaborators to do that is also a unit test. This is called a collaboration test. (Does my class call the collaborators that I expect, with the parameters I expect?, yes you do that by Mocking)

Even though with these two tests, you still miss an important type of test. You still need to test if your interfaces behave as they say they should. Should you test interfaces of external (3rd party) API’s? Probably not. Unless you have a reason to distrust your supplier of the API. Testing interfaces are called Contract Tests and look a lot like State based tests. These tests are making sure your expectations about the interfaces are validated! If you don’t do that you will get defects, even though you test states and behaviors.

Last but not least. It is useful to test broader pieces of behavior. For example, if you use Spring to bootstrap your webapp. You probably need to make sure everything is autowired correctly. That is an integration test. There are multiple types of integration tests. An often used integration test is to connect to a database, put data in, fire up some methods and test their behavior. All of them are integration tests. Hence, even testing whole pages (end-to-end tests) using Selenium, those are also integration tests, although at a much higher level.

In time I will blog more about the type of unit tests.

bookmark_borderMy experience with (un)certainty about estimates in relation to technical debt

Posted on by stefanhendriks

Not too long ago, Martin Fowler pointed out a nice blog post by Jay Fields. Jay Fields refers to a nice talk he had about accidental complexity and essential complexity and how this has impact on your estimates. He found that not all developers consider the accidental complexity and therefor have lower estimates.

I found this a very interesting thought. It got me thinking how I estimate and how far I’m off. I found that, especially with larger solutions, I’m most of the time under estimating. Even with more complex things, and adding some ‘unforseen complexity percentage’. I’m still under estimating most of the time. However, I’ve also had better experience on other projects. Especially the latest project I’m working on the estimates of fixes and rework are not as much off. How is this possible?

I find myself labeling this phenomenom as “lack of overview”. If you read the definition of Accidental Complexity, it is described as “…accidental complexity is caused by the approach chosen to solve the problem.”. I believe this ‘approach chosen to solve the problem’ is the design of the code. This is different comparing to Essential Complexity, which I belief is much like Cyclomatic Complexity.

I made mistakes with my estimates, even when I knew the code well. Often it was due a dependency that ‘got in the way’, or worse, the lack of dependencies. All functionality was in one class! Adding similar behaviour required me to duplicate code. I consider this a bad practice, so I had to extract code from the other class. I was untangling the code. Whenever I had to untangle that code (ie, seperate concerns), I had a hard time doing so: Because untangling a tangled (tightly coupled) piece of code forced me to untangle other pieces of code as well. I had to stop somewhere. Like someone once said to me: The devil is in the details. (this is one of the reasons I encourage my co-developers to talk to interfaces, and not implementations).

But why are estimates off anyway? Is it because (lack) of experience with the code? Even with code I’ve worked with for years I still made bad estimates. And I could not find a way to get them better. The newer project went way better for me to estimate. I already knew why it was going better:

My mental model of the code matched better to the actual code. Was it because I worked on it lately and knew how it worked exactly in detail? No, not at all! The Technical Debt is much lower on this project. One of the principles that played a huge rule was the Single Responsibility Principle (PDF). When I had to make a change, it was often in one place. When I had to add code, I could easily move code out of the class and seperate responsibilities. The code was less tangled, tightly coupled.

This phenomenom of untangling code, seperating concerns and having a hard time maintaining code is clearly a sign of repaying serious interests of technical debt. And I clearly see that as a result of a ‘choosen approach to solve the problem’.

Therefor I believe the technical debt is linked to essential and accidential complexity and even more (what about readability?). Accidential Complexity is something that is very hard to grasp. I think this ‘uncertainty’ needs to be clarified and be added to each initial estimate in order to get a ‘more realistic’ estimate.

I would recommend to estimate code while looking at the code itself, rather than use just your mental model of the code.
Finally, repaying the interest of the technical debt should be prioritized in order to be able to maintain the system and to prevent to get a mad customer getting ever less features using ever increasing time to make them.