Status

Week 1 of the new job has gone well. The Microsoft brain implant seems to be working fairly well. A couple more weeks and they tell me I wont remember that other language that was like J#. C# isn't such a bad language for an Java programmer like myself. At least I don't have to hand code grid layouts. One thing I do like is the way NUnit uses attributes to mark class and methods as test cases. This seems nicer and more flexable than using naming conventions in JUnit. Maybe JUnit could add this feature in a future release.

In other news, I've finally gotten a contract on my next house. I've found a nice little hood down Hwy 280. The area has really been growing super fast in the years I was away in Atlanta. Yes, even in Chelsea Alabama there is a Starbucks on every corner.

Sadly a good friend of mine, Stan Ragan passed away this week from complications related to his fight with brain cancer. Stan and I had a great time in the years I got to know him. We shared the same love for video games and technology. Fortunately we both share the same faith in Christ, so I look forward to seeing him again in the next life. Dealing with losing Stan has provided a time for deep reflection into my own beliefs. It is good at times to question what I believe and why I believe them, since once again I find the answers solid and worthy of my faith. Goodbye for now Stan.

Hammer's Book Reviews

My good friend and mentor sent me an email about several books. I thought his email important enough to share...

From J. Hammer:

Books that I have found useful recently include:

Five Patterns of Extraordinary Careers (Citrin, Smith)
This is good for understanding career paths and your options in muchgreater detail.

Good to Great (Collins)
This book is stunning. What factors would cause an average company topull away from its competitors for a long period of time (i.e., totransition from good to great). A lot of people will read this book,but few will be able to pull off what it recommends. It may alsoirritate you when you realize that you work for (only) a good company.

Execution: the Discipline of Getting Things Done (Bossidy, Charan)
This book had a big impact on my thinking about employee evaluation,employee development, HR, discipline, and (most importantly) businessmanagement that actually knows what it is doing.

Elements of Mentoring (Johnson, Ridley)
Patterned after Strunk and White's classic, this book synthesizes a vastbody of research literature down to what a mentor needs to know.

One more time... reformat reload reinstall.

After reading one more reason why i hate windows from Eric, i have to admit I'm feeling the same towards WinXP. I replaced my mother board; because the MB alarm on my old board was going off. However winBlows XP (eXtra Pain) couldn't boot. The stupid thing would just lockup or reboot during startup. In safe-mode it would stop after printing "mup.sys". After four failed attempts (16+hrs of time) to recover or repair windows I had to resort to just completely reloading windows. Of course this process didn't work well and took two attempts before reaching nerdvana. (There is no way the Matrix could exist if we cant get a simple OS to work) Didn't I just do this about 6mo ago?

Now come the joys of reinstalling all my apps. At least I get to review my list of stuff to backup carefully. Fortunately It means I'll finally get around to updating all my software to the latest versions.

First Apps to Install:

• Mozilla Firefox with the following extensions
  
1. ieview http://ieview.mozdev.org/index.html
2. dictionary search http://dictionarysearch.mozdev.org/
3. bugmenot http://extensions.roachfiend.com/index.php#bugmenot
4. download manager tweak http://dmextension.mozdev.org/
5. copy plain text http://jgillick.nettripper.com/
6. adblock http://adblock.mozdev.org/
   
• Java 5
• Open Office
• Mozilla Thunderbird
• Password Safe (sourceforge)
• CvsNT and WinCVS
• Trillian Pro
  
• Serene Screen Marine Aquarium 2.0 (screen saver)
• JASC Pant Shop
• PowerToys for XP: TweakUI, Power Calc, Command Prompt Here
• BattleFront.com Combat Mission Afrika Korp (look out Matt D, this battle is mine!)
• Savage (s2games)
• Halflife2 and CS Source
  

I wonder how long it would take to reload OSX on a mac mini. I'd bet it wouldn't take a whole week. Funny thing, I've never had to reload my Playstation 2. If I could just send email, print, open office, and surf the net (including flash) on the PS2 or a similar console I wouldn't need a *Personal* computer.

Computer Crash

Yesterday afternoon I was greeted with a siren from my PC and WinXP would not boot. Even SafeMode will not boot. I'm guessing my motherboard is having a fault. Fortunately I have an extra mobo I can use. But it means I'll have to use the kids PC for a while. :(

Java Generics vs the KISS principle

The designers of JSR 014 Java Generics really missed the "KISS principle"

Before Java 5, we only had to deal with a simple class-cast exception:

ArrayList list = new ArrayList();

list.add( new Bar() );

Foo foo = (Foo) list.get(0);  // class cast exception!

This problem sometimes happened at runtime. It is generally a small problem, easily eliminated. Usually good unit tests and functional testing found the problems. The problem was simple enough to understand and explain. Usually even the most junior developers could understand this issue and learn to avoid it with little difficulty.

In Java 5 we now have to deal with Java Generics:

ArrayList list = new ArrayList();

list.add( new Bar() );

Foo foo = list.get(0); // compile time error :)

Everyone's initial impression is "Wow that's a great idea!" Unfortunately the difficulties of Java Generics are not touched in such a simple example. Just take a look at Java thoery and practice: Generics gotchas and the Java Generics FAQs for details about the special problems introduced by generics.

So instead of having to work around one simple class cast problem, we have to work around a complex mess of special rules and gotchas! I have seen experieced developers (myself included) scratching our heads trying to get through the gotchas introduced by Java Generics. All the special rules and problems introduced in Generics are very hard to understand and memorize. Thus Java Generics has violated the "KISS principle." Things really don't work as expected in Java Generics. We have traded one simple problem for a hundred pages of special rules! (Just look at the size of the FAQ)

It will be interesting to see what efforts are made in future JSRs to correct the gotchas in Java Generics. I would imagine adding something to keep the variable's Generic type information at runtime would help.

Six Laws of Software

Interesting article... Six Laws of Software

Advocates very focused, easy to use programs released through small increments. This model certainly works in the Open Source world. But does it apply to commercial software?

Project planning

I read this good article on Gamasutra today: Making Great Games In 40 Hours Per Week (login required, free signup)

A few points I really liked:

• "someone must be functioning effectively as the builder and keeper of the schedule". My personal additions to this is: Some people are better at managing project plans and schedules and estimates than others. The *someone* who owns the schedule should be a technical person, capable of understanding the details of a task. Without the technical knowledge they cant judge the quality of estimates given by the engineers. Also from my experience with XP, I favor measuring the progress on tasks frequently. This feedback is important to keeping the schedule in touch with reality and knowing when its time to replan.
  
• "There should be no such thing as a five-day task" If your task estimate is 5 days, then you need to drill down into more detail to make your estimate. This is difficult in Analysis and Design phases of the project when so much can change later. I agree tasks should be examined in detail to get estimates. However, this detail can create the illusion that your estimates are accurate. More times than not, your estimates are still inaccurate. A multiplier or fudge factor is still required to allow for changes during the project lifecycle.
• "Know What Can and Can't Be Cut". Yes, I learned this the hard way on a recent project. The timeline was set by business factors so that only a minimum implementation could be completed on time. Unfortunately we had nothing to cut! So when the unavoidable technical problems happened, schedule slipped. A project should always have prioritized features, and some fudge features that can be cut.
• "we (usually) add a fudge factor - from 15 to 25 percent - for unexpected events." Howie says he uses a percentage multiplier. I'm impressed that his multiplier is only 0.25. In my experience, I've learned the multiplier depends on the person(s) giving the estimate. Some people typically give more accurate estimates, other people tend to give more optimistic estimates. In addition to the reasons Howie lists for a fudge factor, I would add *reality changes*. That is, during the lifecycle of a project, requirements become invalid because the real world outside is changing. Therefore a project plan must include a fudge factor for *reality changes*, and plan to revisit and modify some percentage of the requirements in the middle of the project's development.
• "Regularly Update Your Schedule" This gets back to my prevoius comment about tracking progress and replanning.
• "Use Overtime Sparingly" Howie goes on to talk about scheduling crunch time. I still prefer adding fudge factors to the plan. Fudge factors come in two forms: features that can be cut and good fudge time added to the plan. However, even the best plans can get into trouble. So I liked his ideas of planning and scheduling crunch times. My last project had crunch time in late December! Yuck!
• "People-Management is Critical" I have yet to work at a company that really does a great job at People Management. However, pretty much all companies I've worked for have done a fair to good job at people management. I guess it is just a trade off between productivity and cost.