Don't be lured to the dark side. Some people advocate CSS Hacks and call them CSS Filters, but if you are a programmer who is interested in maintainable code, look at this chart and tell me that hack isn't the right word.

CSS hacks are not maintainable. Every time a new browser version comes out you have to add new CSS to cover it (and hope it doesn't conflict with older hacks). Every time you change your site, the CSS must be updated for every browser branch that's supported. Just picture yourself as the poor developer who has to take over maintenance of a site like this in a few years; the choice should be obvious.

My advice: be creative.... just do it without the hacks. Yes, I know, I know. You had a really cool idea that takes just a few CSS hacks, and then you're golden. OK now be really creative and come up with something just as good, that doesn't need the hacks.

(Recommended Audio - MP3 from OOPSLA.org)

This talk was given at the end of last year. It contains a lot of great information about creating passionate users for your application (and creating applications that you're users will be passionate about).

The speaker, Kathy Sierra, is the author/co-author of many of the successful "Head First" technical books. She is also one of my favorite bloggers. Unfortunately she left the blogging scene following problems with extensive online harassment and threats from a small group of crazies. Her blog Creating Passionate Users can still be read at headrush.typepad.com.

When I started blogging I threw this site together over a few evenings. I set it up on blogger, which is free, and figured that if I found that I liked blogging I would do more work on it later. Since I've decided that I want to stick with it I think that it's well past time that I clean-up/redesign the site because as a software/web developer, the quality of my site is a reflection on my skills. I have started that process today.

Originally I was going for a blog / wiki concept where I could blog on topics and link to audio, book reviews, definitions, people profiles, and possibly other content. Because this content was separate from the blog it wouldn't clutter up my posts and could be updated as necessary. The additional content was available via a menu at the top and though I was never really happy with this approach, it seemed a good way to start. In retrospect I've found that the additional content was seldom visited, and that working on it was a pain and a distraction. I also thought that the menu cluttered up the site and that the point of the other sections might be lost on visitors/readers, and that a lot of the information was only useful/desirable within context.

If you visit my site now you'll notice that I have removed the menu bar at the top. Also the book review and audio review sub-domains have been disable.

Audio reviews (commentary on talks, webinars, etc) have been inlined with the main blog because I find them valuable. Because of this subscribing to my RSS feed in ITunes or similar software will provide a podcast of my recommended audio. I have removed Book reviews completely as I have found that I really hate doing them. I have decided to keep the areas for people and definitions but these really didn't need to be in the menu as they are just places for me to add ancillary/supporting content that I could link to.

I am still not satisfied with the site and will make further changes to it as I have time. Because of the changes some links to ancillary data in past posts may be broken; I will try to clean this up as quickly as possible. Thanks for your patience while I figure out a better format.

Traditionally when the term Spaghetti-Code was thrown around you would hear talk of goto statements. If this, goto line number (or label)... and when you got there it would send you some place else, which would send you some place else to infinity. It was kind of like procedural programming without any encapsulation or meaningful names, where the code could and did step all over itself, and you had no idea why. If you don't know what I'm talking about, count your blessings.

One of my favorite aphorisms is credited to David Wheeler who says: "Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem." The new form of Spaghetti Code is what I guess I'll call Spaghetti-Code by Indirection or perhaps YALI(Yet Another Layer of Indirection). Essentially it goes like this... You're doing maintenance on some code and you've tracked the problem to a particular method, so you step into the method in the debugger and that method instantiates another class. You go to that class and it gets an object from a factory class. You go to class that's being passed by the factory and it sends you to it's base class, which calls a class in the framework, which sends you to another class, which sends you to another, which sends you to another, which sends you to another, ad nausium.

Twenty layers or more in you find out that the business logic that's causing the problem isn't in the code at all... it's actually in a stored procedure. Congratulations you have just experienced the New Spaghetti code. It comes from overly complicated, poorly engineered solutions. That's why I think design reviews and code reviews are so important; there's no way that a programmers peers would let them get away with something like this, because for all they know, they might just be the next person to work on it.

How many software features have you seen added on like this:

This is a great example of a short term fix... a bunch of bungee cords, a ladder, and a pair of vice grips to hold a red rag on the end. If you're moving a single piece of wood its no big deal, but I have seen far too many features or even whole applications cabled together like this.

Immediate needs require a quick solution... but in software development time is almost never allocated to clean up the mess afterward. That's the myth, that short term solutions in Software Engineering are ever short term. In reality they're left in place until they start to fail or can't meet current requirements. After all, a working feature will never rank as high as the next fire that crosses your bosses desk (and at organizations that regularly do things like this, there is always another fire waiting).

It's maintenance suicide. Short term solutions never hold up to long term use and changing requirements and they are nearly impossible to maintain. Lets take our current metaphor further... what happens when the business comes back and says now they need to move 200 pieces of wood at a time or that they need to be able to open the trunk while moving wood? Clearly the current solution won't work and we'll likely have to start from scratch.

And that's just what happens at short term minded organizations... there is never time to do it right, but there's always time fix it when it breaks or to just to do it over. A few years ago I was at an organization that ground to a halt after 6 years of short-term, business driven decisions. The short term fixes were breaking right and left under the weight of the growing business. Short term solutions are the antithesis of long term stability in a company.

T-Shaped people are people who are deep or expert in one particular skill set and also have a number of complementary or tangential skills that they are shallower in. It is important to note that they do have a primary area of expertise and are quite different from a generalist or a jack of all trades (as the old saying goes, "Jack-of-all-trades; Master of none"). T-Shaped people are like the traditional I-Shaped person, a specialist, but they also branch out wider, where an I-Shaped person will primarily go deeper and deeper.

I like how David Armano relates T-Shaped people to being passionate about different things (basically a primary or core passion and many ancillary ones). I laughed when I read this because one of my favorite questions to ask people is "What are you passionate about?". I like passionate people, especially people who are passionate about programming. Kathy Sierra has said that "People aren't passionate about things they suck at". It's a fairly accurate truism, especially for people who have been doing something for a while.

I've been programming since I was a kid. I love being in-the-code, in-flow -- that state where all the pieces are in your head and everything makes sense and the code just rolls out. I love solving interesting problems, finding clean solutions and building useful things that help people do what they need to do and I don't think I could be happy in a job that took me away from that. That is my primary passion.

And then there are my ancillary passions...

• I've put a lot of thought and study into development methodologies, team dynamics, and people management, but I can't believe I would be happy in any sort of management only role -- too many head aches and no coding. (I have been fortunate enough to have worked under two excellent managers who took the heat, dealt with the headaches and fought for the team so the team could get the job done. To Robert Killory and Miles Andrews, a profound thanks.)
• I had my hands in configuration management for a while. It made me a zealot for source control and for easily deployable applications and I gained a real appreciation for people who can thrive in that role but my time was split between coding and config management and the time that I was away from coding became a painful distraction.
• I love improving business processes (bad processes are a serious pet-peeve) but I'd go nuts as a business analyst -- too much documentation, too little creativity and no coding.
• I have strong feelings about well designed databases and I love tweaking the last bit of efficiency out of complicated stored procedures, but I wouldn't want to be a DBA -- too much tedium, too little creativity.
• I love user interface design and focusing on user experience and usability, but I need to have my hands in the guts of the application at least some of the time or I get restless.

So that's me... I can't stand being pulled away from code for long, but I love doing different things and having input on a lot of different aspect of a project. That, as I understand it, is a T-Shaped profile.

I don't think it's better to be T-shaped than to be a more traditional I-shaped specialist and I suspect having all T-shaped people might have its own hazards, but I do think having a few T-shaped people on any team helps the team dynamics. T-shaped people can bridge opinions between people of differing view points or find gaps where only one view point is being considered.

That's one of the key things that T-shaped people bring to a team: an ability to see many perspectives. Another thing that I think that they bring is the flexibility to temporarily fill gaps within the team and to take on new skill-sets quickly.

It's funny, but on those personality/learning/communications assessments that companies give out from time to time I tend to score fairly evenly across all the areas, leaning just a bit toward the logical/analysis aspects... I wonder if that is common among programmers who consider themselves T-shaped people. Also how many T-shaped people are bloggers? Is any correlation between the two?

You may also be interested in the following posts:

• T-Shaped People VS Generalizing Specialist
• The Renaissance Developer