Thursday, January 25, 2007

Posting from Flickr


DSC_0121.JPG
Originally uploaded by devilelephant.
Testing the ability to blog my Flickr photos directly.

Flickr

This is a test post from flickr, a fancy photo sharing thing.

Back to Blogger

Moved my blog back to Blogger after experimenting with Typo, the Ruby on Rails blogger, on my own server: http://devilelephant.com.

I'll have to work on getting my view back to what it should be.

Lessons Learned:
  • Managing your own blog software is a big job.
  • Typo is hard to upgrade - at least it was for me
  • The version I was using allowed too many spam messages and talkback links
  • Fun AJAX interface is not worth the spam and maintenance.
  • Kept me from wanting to publish.

Dealing with Crap Code

Who doesn’t? Only those who are lucky enough to work on small dedicated teams.

I think it would be an interesting article to face the fact that crap code and low-level developers are a staple of corporate development. The leaders in our industry whine about this a lot but it is a fact of life and it won’t improve due to economic forces. As long as a corporation can pick up a six-pack of developers from Walmart that will work for 50% of what a talented and experienced developer would work for there will be crap code. It doesn’t matter that statistics show the project will take 10x as long or that maintenance costs will be through the roof. I’ve yet to meet a corporation where those concerns matter to anybody above IT manager (if that). Long term maintenance is usually not a planning concern and is part of some other department's budget anyway.

A sad truth is that the majority of crap code performs similar to quality code so many times it is hard to argue for a decent refactoring. I’d be interested in figuring out how to use existing frameworks to better localize the crap code to small crap islands (crapplets?). Early n-tier development did this by letting the so-called junior developers do the 5000-line-per-JSP programming while the experienced developers worked on the server. This was great until people started expecting more usable web interfaces. Now the UI might have as much JavaScript and AJAX magic as the business side of the application.

I have yet to see a software process or framework that tackles this issue realistically. They have “roles” but they don’t specify degrees of capability. When 80% of your team thinks threading concerns are when your clothes start to wear out how do you best place them within a project?

I think it would be fascinating to see a software framework that specifically breaks apart concerns so that you can use your A, B, C, and D developers to the best of their abilities while minimizing the impact of the crap code that the less capable will crank out.

I don’t want to hear any feedback about how you should just get rid of the junior programmers. They have families, they have to eat, and realistically, if downsized, the more expensive developers will get the boot first. Our industry has to figure out how to best utilize the majority of its C and D-level developers. We can’t make them all project-managers.

Commenting fields/methods

Less comments but more content.

Along with methods, if a field has to be commented, I’ve found it is usually because it is misnamed.

// Counter that keeps track of login attempts private int counter;

Would be better expressed as: private int loginAttemptCounter;

It is funny how this simple DRY concept can keep you on the high road of development. Also important is spell-checking and grammar. While a comment shouldn’t be an English thesis paper it should be professionally written. If English is not your strong point have a buddy on the team review your code for errors. Even the best authors lean heavily on editors (the human proof-reading kind not the text-editing kind).

EZ Project Management

No matter what the chosen process is or how tasks are broken up, every major project I’ve been on has been time blocked:

  1. Management decides the new system should be finished by date X.
  2. The analysts and project manager divide the amount of tasks by the number of iterations available before date X.
  3. For each iteration-task-set you divide it evenly amongst your available developers.
  4. You ask your developers for an estimation on their tasks for each iteration.
  5. They respond by taking the number of assigned tasks, divided by the hours available in the iteration.
  6. Some magic happens (scope reduction, overtime, bring in experts to clean up, implement tasks with TODO: statements)
  7. The project finishes on date X.

I’ve developed this project management process on a single MS excel sheet. I’m making it available for a cost of $1000 per seat with an annual $10K maintenance charge. Of course I can offer consulting services to customize it to your corporation at a $300/hour bill rate. Do you like curly fonts?

Corporate Code Smells

Mostly venting here, how many of these have you seen?

Corporate Code smells:
  1. WSAD - There is a reason it isn’t called WHAPPY
  2. Only javadoc is the eclipse message telling you how to change your default javadoc templates
  3. No interfaces at all or an interface for every class
  4. junit.jar exists in the lib directory but no tests to be found
    • I got this unit test that calls the production database
  5. optimized imports? code formatting? we don’t have time in the project plan for that
  6. Sure we use Spring, but we wrap it with our own classes so we can switch it out later
    • We’ve cached the bean instance returned by Spring to speed things up
  7. We added hibernate because we knew we were going to hit the database
  8. Synchronization? Threads? the container takes care of that
  9. Guys, look at this framework I cranked out last night!
  10. With annotations I was able to expose all my classes as web services, you know, for reuse!