The old theme was getting, well, old. How do you like the new one?
There is an interesting German article about agile RE: Gedanken über agiles Requirements Engineering
In his last article, Joel talks how DVCS confused him and how he solved the problem. One sentence in particular should be noted:
these systems think in terms of changes, not in terms of versions.
PS: I prefer Mercurial to Git for
1. I need a working DCVS, not a toolbox to build one. I prefer it when a smart guy has given all the hidden issues some thought, so I don’t have to.
2. There is a simple, working Windows installer.
3. It’s written in Python.
If you’re like me and use Tomcat and you want to bring down the size of your WAR, you’re faced with one issue: All your applications need to use the same libraries (since there is only a single common/lib for everyone). So you’re either stuck with an old version or you need to upgrade all your apps at the same time. I just can see the budget guys shake their heads.
The solution is a list of directories in your context.xml which contain specific versions of the libraries you need. This way, you can install all the versions you need and each app can pick and choose.
For the complete solution, see the original article: Extending Tomcat WebappLoader to Share Library jars
OSS for teh win!
I’m always interested in new ways to display and edit code. ASCII is soooo tedious.
Code Bubbles is a new approach to cut files into fragments which can be arranged per task.
My last post about making software developers properly test their code lead me to thinking about change. We all changed since we were born and not only in size. We adopted new ideas, developed new skills and changed our habits. How long does this take?
Short answer: A day, a year or forever.
Long answer: There is change which just happens overnight. Take smoking. Many people successfully stop smoking all of a sudden. They start thinking what they do, why they do it and they stop. That’s what I call “one day change”. It’s not something which needs a lot of effort, it just needs resolve and a decision.
The year change is different. Imaging you want to give up a habit. Say you talk too loud. Or you’re not as reliable as you want. Or you don’t test your software enough. There are reasons why you should do it. And there are reasons why you don’t do it. Repeat: There are reasons not to change.
A lot of people try to change but they forget that there are “good” reasons why they behave the way they do. It’s more simple, maybe there is a genetic disposition, maybe their peer group supports the current behavior. If you want to change, you need two things:
- The goal must have some positive impact on you.
- A list of reasons why you don’t want to change
The first thing is necessary to make sure the goal is worth the effort. If it’s an uphill struggle with no gain, give up, spare yourself the frustration and try some other goal. Maybe someone else wants you to give up an annoying tick but you don’t see the point. Let me repeat: This is no excuse to have no goals, it just means not this goal.
The list will help you cut all the ties which hold you back. They will make you see patterns, they will make you realize when someone or something is trying to influence you to stay the way you are. So you want to lose weight. But your peers don’t want to waste money or effort on healthy food. Find a way to change that. Not overnight. You have one year. Start with small things. Eat a carrot every day. Try different carrots, see whether they taste different. Grow your own carrots.
Or maybe you eat because you feel bad. Buy some funny comic books that make you laugh. Buy them, read them and then place them next to the fridge. When the hunger comes, get some food and a comic and have some fun. It won’t solve the problem but it’s better than moping, right? You can’t really work on a personal issue while feeling bad, right? So have some fun and when you feel better, maybe you can do something about the real problem. Maybe not but you’ll still feel better.
When you often buy food that makes you gain weight, buy some small containers and spread the food into them. Turn one bag of chips into four small boxes. Store the boxes in a place that isn’t easy to reach. Make it harder to follow your old routine and more easy to follow the new one. Bury the chips behind a bowl of fruit and vegetables.
The year change is hard because it takes so long. If you don’t get positive feedback from the change along the way, you will lose focus and the change won’t happen. Also keep in mind that the change will happen slowly. After the year, you’ll suddenly notice that you changed.
Which leaves us with the forever change. There are two kinds: The Zen change and the impossible change.
The Zen change is something where you get better every day. You can meditate a hundred years and you will get better at it every single day.
The impossible change is change that won’t happen. If you try to quit smoking but you don’t have the resolve, even through they just took your last leg. If you select a fresh salad for lunch and pour half a liter of French sauce over it. If your boss says you must do something but you don’t see the point. When you just can’t see a reason to change. Try to notice it. When you noticed a forever change, learn to be honest with yourself and accept that it won’t happen. Or that you need someone else with an idea how to make it happen.
It’s always the same story and always the same reason: For a change in behavior, expect a year for it to become a habit. Under the best conditions.
So how do you introduce tests to developers? Here are some tips:
1. When they fix a bug, ask “Are you sure the fix is good? How do you know? Ah, you ran the code? Good. Then run the code once more but from a little test.”
2. When they discuss a new feature and can’t decide which way to go, say “How about you write a test for the feature and then try to modify the code so it makes the test pass. This way, we’ll see quickly which way works better”
3. Write some tests yourself. Make sure they run and if they fail, talk to the guy who made them fail. Help them to fix the problem. The bad solution would be to ridicule them, or punish them. Everyone makes mistakes. The tests are there to help to make less mistakes.
If the tests become another problem in the daily routine, They won’t generate enough positive energy for anyone to bother. Result: Failure.
If you meet resistance, ask yourself: What problem do I solve? Or am I just being religious? Do I test for the sake of testing? Or do the tests make everything better for everyone? Do they reduce stress or increase stress? Why?
All these questions will have different answers depending on your specific situation and the answers will help you to find your solution. Paper can’t think, you can. If some rule (out of a book or from your boss) just doesn’t make sense, then it’s your turn to come up with a solution.
There is just one thing to keep in mind and that’s the goal: Tests must help. Everything else will follow.
Here is a nice post by Julian Simpson about how to manage your runtime dependencies (i.e. programs and libraries which your code expects and which you can’t handle with, say, Maven): A way to cool dependency Hell?