ntschutta.com

Congrats to local tech guru Michael Nygard - his book Release It! has been named a Jolt Finalist. Way to go Mike! In case you haven’t noticed, Pragmatic Bookshelf has some awfully good titles…

I had lunch with my friend Dan on Monday (and finally got to a RUM meeting…) and he mentioned that local guru Mike Nygard was on a recent Pragmatic Podcast. As you might expect, I pointed iTunes at the feed and was not disappointed. Mike wrote Release It, a very important book on making sure your code is production ready. Anyway, well worth a listen. Speaking of podcasts, my friends Neal Ford and Andy Glover’s chat on JRuby et al is up on JavaWorld. Good stuff guys! BTW, Andy, if you’re looking for other people for podcasts, I *cough* know a guy.

Just a heads up that I’ll be speaking at Twin SPIN next week - here are the details. I’ll be giving one of this season’s No Fluff talks. Hope to see you there! Unfortunately that means I won’t be at the latest edition of Minnedemo but I think that just gives you an idea of just how much tech goodness is happening in the Twin Cities these days.

In my Test Infecting talk, I do my best to counter a number of myths that I (and others) have encountered when introducing testing into an organization. One of the most persistent misconception revolves around time - or rather the lack thereof. Many a developer has claimed they don’t have time to test to which I generally reply with a Pat Parelli quote from this post on Kathy Sierra’s blog:

“Take the time it takes so it takes less time.”

Kathy was talking about multitasking but my point is simple: forgo testing and you’ll pay that price plus more later when the defects start rolling in. While I *think* this is persuasive, Dean Wampler went one better by using charts which we all know makes for a better argument Dean makes some great points in Why you have time for TDD (but may not know it yet…) though the part about moving unscheduled project end time up earlier into the project really hit home.

Ranges are fine and the key to success is frequent milestones; as we learn more about the problem domain and the technology we are using, the more accurate our estimates. But most organizations take a random guess (with, I’d say, a wind’s spittle of support) and turn that into a concrete date around which the world turns. They then ignore all the little milestones (if they track them at all) or they green shift the project status. The result is failure, though sometimes we redefine that word to mean something else entirely…

Like any industry, ours likes to pretend that today’s problems are new and unique - it’s part of how we justify our salaries. And while the demands on what we are expected to do with technology continues to exceed the gains made with improved languages and hardware, the more things change, the more they stay the same. For example, take collaborative work environments. With today’s focus on outsourcing, far flung offices, and distributed supply chains, using technology to help distributed teams work together is a must. While some people might think this is a relatively new phenomena, in truth, Douglas Engelbart (inventor of the mouse) was working on these issues back in the early 60’s (a point Doug Crockford made in his RWE keynote). A while back, I stumbled upon this video of a presentation from Alan Kay circa 1988.

During the talk, Kay shows a video of Engelbart demonstrating some really amazing stuff. In the presentation, Engelbart works with a colleague located about 30 miles away - along with sharing the desktop, they’ve got full audio and video connectivity. Needless to say, I was pretty wowed.

Further along, you see some amazing applications developed by school children! While some of this may seem quite simple today, you have to consider when this was filmed. I’ve long been fascinated by novel ways technology is applied in the classroom - something beyond using a word processor or doing some research on the web. I have to wonder what has become of programs like those discussed in this talk. Of course now we have things like Yahoo! Teachers but still, the focus seems to be on attendance and grades not on enhanced teaching methods.

These days you can’t swing a short iron without running into some discussion of patent law and how it applies to software (or more often doesn’t apply) but I was really surprised to hear it come up in the Q&A of Kay’s talk! To paraphrase Alan, while he feels that protecting inventions is good, there is “enormous confusion between what’s an idea and what’s an invention”. He argues that there should be some protection but that it is and can be abused. A little later, he argues for more than just a technical education and as a graduate of a small liberal arts college, I was very pleased to hear him urge computer scientists to get a liberal arts background arguing that the challenge is to find the aesthetic. Frankly, I think my BA in computer science makes me a far more well rounded individual and has allowed me to perform a wider variety of duties.

Anyway, a very fascinating presentation by a giant of computing. I highly recommend you take the time to watch these; despite their age, they are still quite timely.

Despite our best efforts, many technology projects don’t succeed (and a few that do define “success” in interesting ways…) Many many words have been spilt trying to answer why failure is so common and even more describing the one true way to counter that sorry state; I’m certainly not going to add to that ink bath but maybe I can give you a heads up that will save you the pain of yet another death march. In a series of chats with various project survivors, I’ve assembled the following short list of signs that you it might be time to find something new.

• “The file extension is .java” is the first item on your code review checklist.
• You throw out a random TLA in a meeting and no one misses a beat.
• The project manager says the data model is already 95% done.
• The use of the term “code smell” is outlawed.
• Developers insist that unit testing will only slow them down.
• Estimates aren’t ranges.
• Your manager tried to send people to Waterfall 2006.
• Technologies are evaluated based on the quality of the golf course.
• The first thing the tech lead does when he downloads a piece of open source software is hack the code.
• The term “Big Bang” is thrown around liberally.
• Your project structure requires an upgrade to your toolset in order to function properly.
• The architect is babbling like the Oracle at Delphi…and everyone is nodding.
• You feel the need to build a “concrete containment building” around a part of your code base.
• Your IDE is responsible for generating nearly all your code.
• All technical questions are answered with a recap of the project history.
• End users have update access to the production database tables.
• You do something special when your page has checkbox3.

Though influenced by my own experience, any resemblance to projects real or imagined is entirely coincidental… [Shortly after writing this, I was listening to a Java Posse podcast that had a nice list of project smells.]

I’m a little tardy in getting the Rich Web Experience written up, I hope you’ll forgive me. First off, I just want to thank the attendees - what a great audience! They were very engaged, asked a ton of great questions and really made for a fun few days for the speakers. In an neat bit of coincidence, I met Josh Holmes from Microsoft on the plane out to San Jose - we spent most of the ride talking about Silverlight though his trip to Crested Butte was quite something! Anyway, I hope Molly Holzschlag is feeling better; her presence was missed but at least the opening panel managed to make InfoWorld (you can’t spell filibuster without Scott Davis ).

Having no talks Thursday, I settled in with a full helping of Bill Scott and Doug Crockford. Bill introduced Protoscript, a “simplified scripting language for creating Ajax style prototypes for the Web.” I thought it was a pretty interesting tool and something that could really help those of us that build UI mockups (read more here). Doug talked about, you guessed it, JavaScript a topic near and dear to his heart (check out his stuff on YUI Theater to get a taste of what you missed).

Friday I had to go to work! I opened up with my Designing for Ajax talk which was a hit. My audience was just fantastic - they asked a ton of questions and I had a real blast with this talk. From the comments I got afterward it sounds like people learned a bunch and had a good time. Later that afternoon I gave Deconstructing Prototype for the first time and it went pretty well I think. Bill’s Antipatterns talk was great; it just amazes me that some of his examples ever made it out to the real world and I applaud him for being able to turn a critical eye towards his employer. That afternoon I taped a short video on UI/JavaScript etc. that will someday find its way to the NFJS site - I’ll be sure to post when it goes up.

Jesse James Garrett’s keynote was quite something; his slide deck was quite a work of art and had many of the speakers buzzing. He’s clearly a believer in the Lessig/Presentation Zen method; the use of images and words plus the integration of blank screens was worth the price of admission. I also enjoyed the case study from the Netflix folks; they’ve got some great examples of Ajax on their site but what I respect so much is their belief in testing. According to Sean Kane, about 70% of the features his team dreams up never make it out of testing!

During the second expert panel Scott threw out the “what books do you recommend” question and as usual Neal Ford stole two of mine (Dreaming in Code and another that I’m surprisingly blanking on). Needless to say, I’ve got a few things to read in the coming months - here’s a list of what I jotted down to follow up on:

• The Lucifer Effect
• Facts and Fallacies of Software Engineering
• Misquoting Jesus
• Hiding the Elephant
• The Change Function
• Pattern Recognition

While I really enjoyed the entire weekend, the highlight was Aza Raskin’s workshop on design. He discussed the “monologue box” (aka JS alerts) along with his solution of transparent messages. His examples of undo on the web were inspirational sparking a lot of discussion. Throughout his talk he showed off Enso and though I love Quicksilver I wouldn’t mind if Humanized ported that bad boy over to the Mac! Aza talked a lot about natural language which lead to the quote of the week:

Trying to remember the command for tar -gvf is like bobbing for apples in a cement mixer.

Aza was good enough to join a handful of speakers at dinner after the show and he even tagged along for a couple of hours of pool. Good thing he and I are pretty close in skill at that particular game…though he did school me in air hockey.

Needless to say, it was a great evening and fantastic way to wrap up the conference. Neal and I did our best to recruit Aza for NFJS, he’d certainly be a welcome addition. Anyway, a great show and I’m really looking forward to next year when we’ll have not one but two opportunities to get the web community together!

The last couple of days I’ve been involved in what I would essentially term a code review of some things our off shore team recently completed. To say there were some issues would be a bit of an understatement and it has certainly helped cement the need for continuous integration, frequent review, and a strong test suite. While I expected some odd use of inheritance, the empty interfaces caught my eye and I spent longer than I like explaining why YAGNI would be the team’s default position on pretty much anything. But none of that is really worthy of a blog post - that’s just run of the mill coding stuff. No, the real inspiration was this little gem:


public class Constants {
  public interface UIConstants {
    public static final String foo = "foo";
    public static final String bar = "bar";
  }
}

Now, I know some people think that interfaces are the cat’s meow for storing constants, heck, I even did it once in a past life (I was young, I needed the money) but I’ve vowed never to follow that antipattern again. Don’t just take my word for it - Joshua Bloch calls it out in his must read Effective Java (I for one can’t wait for the updated version). I’ve done my part to eradicate this erroneous use of interfaces but when I saw the code above I was floored.

Frankly, I’m a little surprised it compiles but unfortunately it does. Of course I found myself asking *why* anyone would even think to use this approach. Wait, I can hear it know “we only have one place to go to look for constants and we have namespaces too.” Um, OK, then please explain why there were a couple of other interfaces that were also called Constants and did you catch the whole antipattern comment? Furthermore, explain why you think it makes any sense at all to have an interface as a member of a class. Talk about abusing the constructs of Java.

Needless to say, we extracted those so called interfaces into real honest to goodness classes that couldn’t be instantiated. And for those of you that will complain about how painful it is to write UIConstants.foo in your code, have you heard about static imports yet? Should you go down this road though *please* don’t go overboard; as the Sun guide says:

If you overuse the static import feature, it can make your program unreadable and unmaintainable, polluting its namespace with all the static members you import. Readers of your code (including you, a few months after you wrote it) will not know which class a static member comes from.

Needless to say, it’s been an interesting few days reviewing this code - I wait with bated breath to see what next week brings.

I’ve long exposed this wisdom that was given to me by some sage but that an engineer would take the time to build it into, of all things, a Microsoft development tool really tickles my fancy!

Via Tech Republic.

Recently, a friend of mine and I were talking about the Big Ball of Mud pattern especially as it pertains to staffing. When you’re dealing with spaghetti, technical skills aren’t nearly as important as familiarity with the code, a truth captured nicely in this quote:

…architects depart in futility, while engineers who have mastered the muddy details of the system they have built in their images prevail…This advantage can extend to those programmers who can find their ways around such code. In a land devoid of landmarks, such guides may become indispensable.

Now, I understand that in many organizations, knowing the path through the swamp is a vital skill and many individuals have made very good livings out of being guides. But problems crop up when people start confusing comprehension with competence - knowing the back way to your house doesn’t make you Magellan.