Repeat after me, "Objects have behaviors and attributes..."

I was catching up on Martin Fowelers blog and caught this article on FluentInterface. This would be a great way to set up your domain objects to collaborate. It also reinforces another idiom - make your API as "natural" as possible, not just a bunch of getters and setters and a functions to tie them all together.

Speaking of which - GetterEradicator is a fantastic article off of Martin Fowler's bliki that addresses what your objects public interface should be. Great quote from the article.

The OO community may have 'won' in the sense that modern languages are dominated by objects, but they are still yet to win in that OO programming is still not widely used. As a result it's still common to see procedures that pull data out of an object to do something, when that behavior would better fit in the object itself - a violation of the pragmatic programmers principle of "Tell Don't Ask". You can only do this kind of procedural programming if you have getters, so telling people to get rid of getters helps push them to move behavior into the right place.

(Special thanks to HoR for sending a reference this out to our Dev team!)

It is never too late to do the right thing.

I'm hoping to develop here a strategy to get management buy in on architectural changes that should happen (need to happen?) as my project moves forward. This is going to cost development and QA resources.

The backstory:

Currently, I am working on a project that was "acrhitected" in 2000. It's a fairly large web application, that followed the "model 2" servlets/JSP pattern, and the Servlet 1.0 spec. In 2000, the company was a startup, we had about a dozen employees and 3 customers. We had an architect, an OO-consultant, and a lot of enthusiasm. Me? It was my first Java project. I was clueless.

As time progressed, we developed harriedly with little process. We had to develop a product that people wanted to buy. Hours were long, but we were fairly successful replicating features based on the servlet-per-JSP model. We had our own persistence framework, and our own data caching solution. Meanwhile, 5 years pass, J2EE matures, frameworks are born. (The truth is that many frameworks existed already that we didn't take advantage of). We are a J2SE application trying to fake it in a J2EE world.

Now that the application is huge and our customers are many, we are really feeling the growing pains. The solution up until now has been to throw hardware at the problem. Unfortunately, this has always been just successful enough that we haven't ever gotten schedule to get to the root of the issues.

We have always been in the position where retro-fitting new technology into our application would be an large undertaking in both development and test - and fraught with risk. So here we are.

Where do we go from here?

Well, that question is a good starting point. I need to determine what our truly critical flaws are, and get a plan together that addresses those first. In order to get the business plan to buy in, we need to address things that will show a little ROI. Everyone loves ROI. Sometimes, "so we don't crash" is as good as money in the bank (especially if software crashed yesterday).

Build it.
I'm confident now that the KoD for any proposal, especially when it involves expensive engineering resources, is to start your pitch with, "I think I can demonstrate that..." You can't sell it on paper. If you're selling technology, then you must demonstrate that technology. Build it and they will come... (at least that't the hope). There are several benefits to prototyping it before pitching it to mgmt.

• You may be dead wrong - for whatever reason the prototype doesn't work out.
• You mitigate perceived risk.
• You improve your own depth of knowledge on the topic.
  

Have an incremental plan.
As you can imagine, "rewrite the app" is not an incremental plan. However, introducing alternate technology to do the same thing as existing technology is not an evil thing. Matter of fact, we have done this to some extent in our own application. We recently implemented some of our new screens using JSF, instead of marked up JSPs. I can't imagine that all of our other screens will go to JSF, but we're doing all new development that way.

Anticipate differences.
Using a different underlying technology/implementation may force you to handle some things differently than how things are currently done. When implementing JSF, one of the things we failed to manage was differences between how JSF and JSP handled form validation. JSF has its own validation framework. It's pretty well thought out - however it typically expects a server-round-trip to happen. Our existing JSPs had some pretty extensive client-side javascript validation. The difference wasn't huge, but it did change the user's experience somewhat.

Sometimes these differences are beneficial, sometimes detrimental. In our case, it wasn't a big deal, but the difference added to the conception that our moving to the new technology was the wrong decision. Had we thought about the differences, we could have probably also done client side validation before we shipped - and the user would have been none the wiser.

There are two goals that are typically going on in parallel. When refactoring, we're looking for the highest impact change in the lowest impact way. If execution speed is your issue, the very best we can hope for in a refactoring is that the user logs on the next time, and it's faster.

Sell it.
I work with a guy who, even though he went to a fine liberal arts college, apparently missed the class on salesmanship. You've got to make sure there is buzz around your ideas, and that they are constanly getting good press. Take opportunities to point out how the development-community-at-large is moving in the same direction you are. Forward online articles around. It's a little sad that you have to play the role of a circus barker, but there's truth to the old addage:
"Early to bed, early to rise, work like Hell and advertise!"

It's in the spec, man...

Lesson #1: Know your technology specs.

You know, there is just no replacement for knowing your specs. And I mean, really knowing them.

I remember reading Stroustrup's book on C++ about 10 years ago. It's not a great book, but it was the most approachable C++ language specification as there was. I didn't find it particularly well organized or helpful - and unless you had a pretty decent foundation of the language already, it was pretty much useless. (YMMV - please no hate mail from Bjarne-fanboys, I'm just setting up my next point).

Java specifications are quite accessable. I'm talking the Java language spec, J2EE spec, and whatever technology de jour you are confounded by. I have a friend and co-worker who lives and dies by "the spec" - and he knows his stuff much deeper than most because of it.

The Java EE Specs for 5.0
(On a side note, looks like Sun has moved away from the "2" in J2EE.)

Let the specification be your go-to-guy. He'll rarely let you down.