Caffeinated soap (or Caffeine can kill your creativity!)

This has nothing to do with software development, but seems to cool to left it uncommented: Caffeinated soap!
Feeling too sleepy in the morning and need an extra kick?
In a hurry and without time to shower AND have your morning coffee?
This looks more practical than getting in the shower with your favorite coffee mug:
you will absorb the caffeine through your skin while showering!
(ok, maybe it has something to do with software, it comes from ThinkGeek, and most of the it workers I know are totally hooked up on coffee… myself included)
But use it with caution, as caffeine hurts your creativity!
Yes, my friends, that wonderful black beverage, your companion of many lines of code, is not your best friend when you need to innovate… looks like creativity is associated with alpha brain waves, but the alertness state provided by coffee is associated with beta brain waves (focus, high attention), so when you need to create a solution, leave the coffee aside (or drink the bare minimum to keep you awake)
BTW music seems to have a similar “creativity killing effect”, but that is because listening to music occupies your right brain (the one you need to be creative!). Maybe is all pseudo-science, but if you’re drinking coffee while listening to music, don’t expect to have your “eureka” moment… consider yourself warned!

RUP and risk management

I must admit that I like the Unified Process. The more non-trivial the project is, the more I think is applicable.
Typically, RUP is presented as a use-case driven, architecture first, iterative-incremental process divided in four phases: inception, elaboration, construction, and transition.
Somehow, using a manufacturing metaphor (I know, I know... usually are the worst ones, and can't go too far), the project can be divided into 2 major stages: "engineering" (inception and elaboration) and "production" (construction and transition).
The good thing is "engineering" aims to reduce significantly the risk level of the project. The biggest uncertainties at the beginning of a project are usually related to requirements (and scope) or technical ones, and they have a big impact because they’re the major sources of cost and time overruns. The traditional approach like the “waterfall” process is to pinpoint all the requirements and then complete the design to the detail (what the “agilists” call “Big Requirements Up Front” and “Big Design Up Front”). I will not beat the “Waterfall” straw man, it has its niche (albeit a lot smaller than most people think). Other option is ignore them and hope that the team is “agile” enough to respond to the risks when they materialize.
In the case of RUP, there’s an explicit intention to “defuse” those risks, by exposing and validating the assumptions as soon as possible:

• the inception phase main goal is to discover what it should be done (usually identifying most of the use cases, and detailing the most critical ones)
• the elaboration phase main goal is to define how it should be done, by defining the architecture of the system (based on the critical use cases)

After those phases are completed, you will have the architecture of the system, feedback from the most critical use cases, a clear view of the scope, and no technical surprises awaiting. At this point you should be able to have an accurate estimation of the total project effort, and the total risk exposure of the project should be significantly lower...

Lego blocks and Software development

When I was a kid I spent hours playing with Lego. Back then, they were expensive and hard to get :-). I slowly grew my collection by a couple of small sets a year. Usually I assembled the original model only the first time, then I put all the pieces in a pool and I assembled many different things.
Now in a different place (and many years after), I bought one and started to play around. Then it struck me: is no surprise that I enjoyed building things with lego and now I enjoy building software. Usually I started with some idea in my mind of what I wanted to build (a plane, a spaceship, a robot) and then scrubbed the heap of parts looking for the right ones, and slowly assembly them together into bigger ones (always spending a significant amount of time looking for the right piece) until I created something that wasn't what I envisioned originally, but at least could pass for it :-D.
Don't you think the process is very similar to write a program nowadays?
You start with something in your mind, and start putting together small pieces (lines of code), search for the right part (in the APIs), group them together (in methods, classes and packages) following your mind, until you get something working that is not what you wanted at the beging but it serves it purpose!
(well, I guess most of the creative activities share common things, but I think is an interesting metaphor... )

Microsoft Certified Architect

I just came from the IASA Atlanta chapter meeting where the Microsoft Certified Architect (MCA) program was presented. Very interesting. The basic idea is having an architecture peer certification that doesn't get diluted. The process involves a presentation of a previous project and then go through hard questions by a panel of 4 fellow MCAs. They're going to look for evidence you have the skills to be an architect, and they want to know what decisions you made in the project and why. As I understood, is not only for Microsoft based technologies.
Seems very though, they're aiming professionals with at least 10 years of experience...
At least looks like it would be more meaningful than the Sun Certified Enterprise Architect (SCEA) in the sense that for an MCA you must be an architect already, and for the SCEA not (you will be architect after the exam).

JavaServer Faces in the real wolrd

I wrote a paper presenting the JSF framework: JavaServer Faces in the real world. I used JSF last year to build custom functionality integrated into a workflow portal. I'm pretty satisfied with the result. I know JSF has been criticized an some of the points are valid, but I think is better than Struts and far better than JSP/Servlets alone. The ability to integrate components from different libraries (like the Tomahawk components) makes development very easy. Also AJAX integration is very promising (although is not as straightforward as it should be).
Read the paper and tell me what you think...

Books

I just added a list of the books I own that I consider important. Of the list, I consider "The Mythical Man-Month" and "Peopleware" two fundamental books that everybody involved in software development. Reading "The Mythical Man-Month" is almost sad when you discover how little our industry has learned. Ok, some organizations learned, but I know a lot that don't. And those looks like the dinosaurs struggling in the tar pit of software development. "Peopleware" is a great complement of the other book, very good ideas and the focus on the most important component of software development, the people! I think somehow Tom DeMarco provides the elusive "silver bullet" formula: smart and motivated teams will succeed in software development. Sometimes, "Peopleware" looks a little unrealistic and unsound, but I believe is part of the idea of the book, it should inspire to look beyond, to the people who creates software.
I must say I had the opportunity to at least try to apply the basic ideas of team gelling and the results where great. (I really enjoyed leading the "13 Guerreros"...).

“Protected” considered harmful (ok, not harmful… useless)

Currently I’m refactoring an old java code (ancient… almost prehistoric I must say). It was obvious that when they wrote it, java wasn’t mature enough and the techniques applied neither. As an example, it had a deep inheritance hierarchy (a classic OO beginner mistake… been there, done that ). I don’t want to bash the current code (or submit it to the daily WTF), because when I look at old code, I usually think: “hmm… that should be better if we did it this way…” (well, who doesn’t think his way is THE way ?), and now I have the opportunity to really do it, so I’m enjoying it.
The code also had a lot of protected methods intended to be invoked by subclasses. I remembered when I started learning OO (10 years ago? Darn, I feel a little old now…) that we should avoid protected.
Protected is like public but for some classes…
For fields, if you adhere to the philosophy that no field should be public, I think protected should be avoided for the same reasons that public should be avoided for fields (I should blog about it later). For methods, is a little more tricky, but if you think that the method could be used the object, why not make it public? If not, should be private. A special case maybe is when you want to provide special access to methods to modify the private structure but only in the context of a subclass.
After discussing it in comp.object, I came to the conclusion that with protected one can do nice implementation tricks, but it should be avoided because it asks for maintenance problems.
The only place I could think where protected doesn’t looks bad is for providing the callback points for a template method.
Well, maybe I have it all wrong, what do you think? :-D