Postel’s Law

Be conservative in what you send, liberal in what you accept.

Parkinson’s Law

Work expands so as to fill the time available for its completion.

Pareto Principle

For many phenomena, 80% of consequences stem from 20% of the causes

Sturgeon’s Revelation

Ninety percent of everything is crud.

The Peter Principle

In a hierarchy, every employee tends to rise to his level of incompetence.

Hofstadter’s Law

A task always takes longer than you expect, even when you take into account Hofstadter’s Law.

Murphy’s Law

If anything can go wrong, it will.

Brook’s Law

Adding manpower to a late software project makes it later.

Conway’s Law

Any piece of software reflects the organizational structure that produced it

Kerchkhoff’s Principle

In cryptography, a system should be secure even if everything about the system, except for a small piece of information — the key — is public knowledge.

Linus’s Law

Given enough eyeballs, all bugs are shallow.

Reed’s Law

The utility of large networks, particularly social networks, scales exponentially with the size of the network.

Metcalfe’s Law

In network theory, the value of a system grows as approximately the square of the number of users of the system.

Moore’s Law

The number of transistors on an integrated circuit will double in about 18 months

Rock’s Law

The cost of a semiconductor chip fabrication plant doubles every four years.

Wirth’s law

Software gets slower faster than hardware gets faster.

Zawinski’s Law

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Fitt’s Law

The time to acquire a target is a function of the distance to and the size of the target.

Hick’s Law

The time to make a decision is a function of the possible choices he or she has.

Lehman’s laws

 Continuing Change — E-type systems must be continually adapted or they become progressively less satisfactory.

 Increasing Complexity — As an E-type system evolves its complexity increases unless work is done to maintain or reduce it.

I’m probably missing some, any idea’s?

From the quick start:

Quick Start
 * Download the latest release from http://sourceforge.net/projects/statsvn/
 * Expand the zip file into some directory, e.g c:\statsvn
 * Check out a working copy of the desired SVN module into
 some directory, e.g. c:\myproject.
 * Change into that directory and type
 'svn log --xml -v > svn.log'
 * Change back to the c:\statsvn directory
 * type 'java -jar statsvn.jar c:\myproject\svn.log c:\myproject'
 * Open c:\statsvn\index.html in your web browser

Regards,
Andries

I’m finishing The Last Lecture, a book I advice to any and all. Truly a life changing experience. Following paragraph is a synthesis from a chapter.

1. Time must be explicitly managed, like money.
2. You can always change your plan, but only if you have one.
3. Learn to delegate.
4. Ask yourself: Are you spending your time on the right things. Prioritize and filter.
5. Develop a good file system. Order is efficient.
6. Rethink the telephone: do it either standing up or with a time pressure. Don’t spend your time with calling all the time.
7. Take time outs. Real timeouts without interruption.

Keep your inbox clean!

I’m a big fan of GTD. Especially when applied to organizing your inbox. I spend quite a lot of time reading and writing mails, taking action on them, etc. My Outlook client is open all the time.

Before I worked with GTD, my inbox was staggering, mails could not always be responded within appropriate times or actions got lost. It’s not very pro if you have to receive reminder-mails.

Now my best advice is to follow these simple rules (copy/paste from the Wikipedia article ):

• Start at the top (In case of mails, this would be the oldest mail)
• Deal with one item at a time.
• Never put anything back into ‘in’.
• If an item requires action:

• Do it (if it takes less than two minutes), OR
• Delegate it, OR
• Defer it.

• If an item does not require action:

• File it for reference, OR
• Throw it away, OR
• Incubate it for possible action later.

If it takes under two minutes to do something, it should be done immediately. The two-minute rule is a guideline, encompassing roughly the time it would take to formally defer the action.

My inbox is in the end of the day almost always empty. More importantly, the easy-respond mails get done very fast, which gives a much faster average time on processing the mail. It really does!

If you like to see more on GTD, start with the wikipedia page. Also the book by David Allen is very good, so I’ve been told.

Until the next,

Andries

I don’t have a RAID configuration, I do have over 1.5 TB of hard disks, and I spread the photo’s across several. It’s not super secure, since all disks are connected to the same computer…

This week I stumbled across jungledisk, a frontend tool for the Amazon S3 webservices. The S3 provides data storages for 0.15$ per GB per month. This is far cheaper then any home made backup system, I’m sure.

Jungledisk provide a mount point (Win,Linux and Mac!) that contains your space on the S3. Whatever you copy onto it, will be cached and uploaded in the background. So it seems very fast. Files are cached locally so you don’t need to retrieve it from the webservice every time.

Now I’m confident my data is stored safely, without a hassle. I’m happy to pay for such a great service.

• Enables loose coupling between interacting classes
• Makes it easier to test
• Allows us to easily switch between implementations.

Lately, I’ve been openly questioning if we should always use interfaces. Are they always required by default and is the extra cost of keeping the interface and the implementation in sync worth the trouble? Lets discuss.

When we are using dependency injection, the coupling between one class and another is very low. It’s of course true that by injecting implementation instead of interfaces we are making the coupling a little tighter. The classes are still in isolation, since neither creates a new instance. This is still done by the DI container, which deals with instantiation and configuration.

Is a class that only has interfaces as dependencies easier to test then classes that have implementations as dependencies? Most of us are eager to say yes, but in fact, frameworks like EasyMock enable us to mock (non final) classes. We can add behavior just like any other interface.

When writing an application, it’s very rare to change the implementation of an interface. Almost all my interfaces have exactly one implementation. Sometimes this is not the case naturally, but I find it pretty easy to spot those implementation that might or will change in the near foreseeable future.

If we should reduce the amount of interfaces in our code, the advantages could be:

• Less classes which (should) equal to less configuration and maintenance
• Less synchronization during development so results in a little faster velocity

Anyway, this is purely speculative.

Let me state that I’m not thinking about actually dumping the interfaces. It’s a proven practice, but I’m think out loud and for myself. What I’m looking for is an insight or story that will convince me either way. So if you have any, I’m more then eager the hear!

Andries

Now we have bugs coming in on a steady stream, but I started wondering how to choose the best bugs to start with. After some pondering, I came up with following:

There are 2 special kinds of bugs, the easy wins and the investment bugs.

Easy wins are bugs (small or large doesn’t matter) that are relative easy to fix. I didn’t say fast, since if it contains a large portion of the program, it could be taking more time then a more difficult bug. Instead it’s just something you know how to fix, like fixing a typo. You’ll spot an easy win when you see one.

Risky fixes are the pain. You need to make a critical adjustment before fixing the bug. Worse even, if you can’t guarantee for sure that no new bugs are introduced. It could be fixed fast, but may involve a hack. A good example is when you have done something a hundred times in one way, but then the 101st time something has to be done just a little different, and you need to change the code a little…

Anyway, now came the more important question: Do I fix the easy wins first, or go first for the risky fixes?

Fixing the hard ones first, seems like the most obvious choice. Start with the hardest, work your way down. Going a little bit further, you know that you might introduce new problems. In fact, you might introduce a new bug (feature!) into an already broken part. Tricky to fix, 2 bugs at one time… As always, but especially with the risky fixes, time needs to be invested to get to the best possible fix. So bug fixing is slow when starting with these ones first.

So, going for the easy win looked like a great way then? Well, it sure gets the bug fixing up & running. One bug after an other gets tackled, leaving only a handful for the last period! But the last ones are going to introduce new ones, right? Actually we are giving a wrong image, the amount of bugs reported and not fixed might seem low, but the work behind them is still large.

I finally decided to go for the risky fixes first, for the following reason: when introducing new bugs by doing the risky fixes, the chance that those bugs are spotted is larger because

• The time spend testing is larger since the bugs are fixed at the beginning of the test phase,
• the other bugs need to be fixed as well, which might expose new bugs (not create) when fixing an easy win bug.

Last but not least, I’d like to close with a final thought. I don’t like it when 2 of my developers are doing a risky fix on nearby code. When one of the two go wrong, it’s a little harder to spot which of the 2 caused the problem. I like to mix and match, letting the risky ones go first 1 at a time, filling the rest with easy wins. Luckily, the easy wins outnumber the risky fixes!

In this post I’ll share some of the lessons I’ve learned to efficiently use the time that was given to us. I’ll try to prioritize and put the more important ones on top.

Set goals

It’s a biggie, one should stop and really answer the question: What do I want to accomplish? I use a great tool for this: FreeMind. It’s a mind mapper that really works for me (Helping by reporting bugs btw).

If you set goals, one can work efficiently in the right direction. If you just follow your gut feeling, you’ll change more directions then socks. Keeping clear goals allows you to set milestones into your life. Reaching milestones are from my experience, the ultimate thrill. Goals can be very long term, but try and pinpoint milestones, no more then a handful, that are within reach.

Of course milestones and goals will change. But since you made a rational decision about setting a goal, it’s harder to toss it away later. There is an investment in a goal already, that you just don’t want to lose.

Let’s look at an example: imaging you want to learn how to learn to cook (is one of my goals btw). Since you don’t know how to cook, the first milestone is easy. Get an easy cookbook. Get good cooking gear (What’s that? Finding out is also a milestone) . Decide what kind of cooking interests you, etc etc.

Plan out your days

Eisenhower once said: Plans are worthless, but planning is everything.

Don’t waste time doing nothing, instead plan out what you will do. Don’t over plan, but at least firmly lay down what should be done in the day. Once plans are made, it’s easier to finish everything. Less distractions (what to do next?) means more effective time used.

Prioritize

Learning how to prioritize, prevents important tasks not being done. Doing the most important right away (when appropriate) is a very efficient way to get things done. Don’t waste time doing very lower priority items, while important stuff needs to be addressed.

Another related item: make time available. This is not easy, sometimes to get something done, something has to be discarded. Wanting to do everything, or worse wanting to do a little bit of everything, is the perfect formula of actually doing nothing at all. I made time to finish this also, it was ‘done’ for weeks now but hadn’t reviewed it.

Organize tasks

Tasks should be organized. Keep a to-do list, keep track of items in progress. Keep a good schedule. Tasks should have a finish. Clean room isn’t a real task. When is a room clean? Better would be: pick up clothes, clear dust and make the bed. For IT related tasks, keep following in mind: SMART.

Learn to sleep less.

I used to sleep 8h straight, every day. After a couple of months of training, this can be reduced easily (at least of me) into a 5h nap. A couple of hours extra daytime is the difference between doing nothing but work all day, and having some time to do something you like.

A couple of tips to start sleeping less:

• Go to bed and get up on a tight schedule during the week. It really helps to train your body to start sleep right after you go to bed. Getting up also gets easier when it’s on the same time every day. Don’t snooze half an hour, cause it’s just teasing and it’s very inefficient.
• Don’t start skimping an hour of sleep. Start small, like 10min. Get into a rythme getting to bed at a regular hour. After you are used to the shorter sleep time, stay up another 10-15min. Again wait until you are adjusted before reducing the sleep any further.
• Don’t work during those extra hours of daytime! Instead spent time on yourself. Do something you didn’t have time before. Read a book, watch a movie or have sex. Do something you feel is a bonus on your day. Trust me, it’s really import to keep the sleep from setting in. Once you are doing this for a some time, you can work from time to time, since you don’t feel tired before you normal sleep time.
• Don’t under sleep. I tried going below 5h15min/day but I felt bad during the day. I wouldn’t die at that rate, but I didn’t enjoy myself. Don’t under sleep!
• Caffeine is your best friend!

As always, feedback is appreciated!

Regards,
Andries

Depth first or breadth first?

Should I learn as many topics as I can, learning as many different technologies? Or should I pick a few, learning everything there is about them? I believe I should do both because the following reason. To go into depth on a technology, learning everything their is about it, you need to have on hand experience with the technology. I’ve found, the best time to learn a technology is to learn it as you are working with it on a project. It enables you to work faster in the project, deliver better quality since you understand the technology better.

Breath first studying is more suited for general knowledge, best practices, project management and so on. I’ve found that reading blogs really helps to keep up with the fast it-world.

Find the resources

I get my general information from RSS feeds. There are some good aggregators out there, like dzone. I use Java weblogs , SDN, JavaLobby, OnJava .

Further, there are some very interesting people out there. Joel , Karl Baum, Raible Design, James Gosling, Peter Veentjer are my personal favourites.

Other resources are books. Some books are absolutely a goldmine. Since I started working as a pro, I’ve read following books:

• Effective Java by Josh Bloch. I definitely LOVED this book. This one really teaches a lot about good solid programming. Probably the best book if you want to learn to code like a pro.
• Head First Design Patterns. Another great book. I knew at first some of the GoF patterns, but after reading the book it gave me a great insight into some of the nicer coding styles. It is a good addition to the Effective Java, since this book does cover best practices on a larger scale.
• Expert Spring MVC and Webflow. As preparation for my first project, which was in Spring and WebFlow, this book provided a lot of information. The Spring MVC part (which is the largest part by far), is really good. It doesn’t cover everything, but provides a very solid basis for this technology. The webflow part is very outdated. I could not find 1 code example that actually works as is. The code is based on release candidates and the code base changed a lot during that time. It’s frustrating and hard, I don’t recommend learning webflow from it.
• Java Persistence with Hibernate. I love Hibernate, and this is the definite guide to it. (There is Hibernate in Action, which was the predecessor). Now this book is not easy, but it starts from the base. After reading this book, you know everything there is about hibernate.

I’ve read some more books, but these were my favourites.

Then thirdly I use forums to expand my expertise. Currently I’m fairly active on the Spring forums. Helping others truly does help yourself. It makes you think about certain problems, and to be honest it’s hard to provide adequate answers. Also you are involved in problems you don’t experienced in real life. The next time you would have that particular problem, the answer you’ve read will help you straight away.

Lastly, I’d like to point out that I’m using this blog as an investment in myself. Learning to formulate my thought into a solid text is very hard for me. I spend time trying, and by trying I’m learning. It easy to know something but hard to express it into an understandable way to other. I believe this blog will eventually help me communicate (by letter mostly) to other people.

As always, I’d love to answer to any comments you might have. Thanks for reading and see you the next time!