Code, Compile, Deploy!

How sending my job to India saved my job.

2008-10-08T22:41:00.008-04:00

This past Summer, I had the opportunity to travel to India. Here is some quick background on how exactly that happened.

On January 2, 2008, I came to work to be greeted with a departmental meeting. Turned out that my company's corporate office had just purchased my product's biggest competitor. Their product had a benifit over ours in that they had a post-acute module for providers that spins off a very healthy amount of $cash$ for the company. No reason to keep 2 versions of the same product, so they decided to retire our product (though some active development continues).

The plan was to go hire a bunch of indian developers in Bangalore to maintain my product, while us developers moved onto the newly acquired product. I was chosen to get my passport/shots together and it didn't seem like long before I was on a plane for 26 hours from RDU to London to Bangalore.

Creating the team

Prior to arriving, we phone screened dozens of candidates. We worked with a contracting house to arrange interviews which I conducted over a desktop sharing tool called Microsoft SharedView.

The interview was challenging, sit down, open eclipse, write an app according to a spec that I give you. We sit there and watch their every keystroke. Once guy caved in and gave up under the pressure - he refused to continue! We got ourselves down to a shortlist of about 7 developers. We decided among ourselves down to 5, which is how many spots we had to fill. We made offers to 4 of them. All 4 accepted.

But will they all show up?

Plans were made that I'd travel to India to provide some on site training on our source code, development process and source control, development patterns, etc. When I arrived in India, for the first day I was totally sick. I got to stay in the corp apartments on Airport Rd in Bangalore and recover while I watched IPL Cricket. Barbara and Becky did introductions and the first training day was pretty light. The amazing thing was that the 4 developers and 2 QA all showed up to work.

I talked with Umesh, the CEO of the resource provider, and he said in this market competiton it was very common for developers to interview, be given an offer, accept - but never show up for work on the first day. The will take another job. Everyone was eager to take this job. Apparently, this happened because of 2 things. The candidates respected us because our interview was hard and our standards were high. Second, they respected that we treated them with respect - and talked with them as collegues. I can't emphasize these two points enough regarding successful interviewing in India.

The cast:

Angles. He is very quiet. Still waters run deep with this one. He's probably the most experienced of the bunch. Angles has a booming deep voice - even though his English is very good, his deep voice makes him hard to understand on a speaker phone.

Vinod. Vinod is a good guy. He is eager and appreciative when learning new things. He's not just trying to pad his resume with abbreviations. He takes pride in his work.

DeepaJ. She also is an excellent developer. She is not afraid to get into the code to learn how something works. The other developers tease her a bit because "the red comes when she talks to David" - she blushes :) It is certainly doesn't hurt my feelings at all.

Kalyan. Kalyan is also great. He has a good understanding of how things work, and picked up things very quickly in our training. He works hard helping us in the reporting area after we lost Philip and Nathan. The best thing about Kalyan is that he looks like he is smiling even when he isn't. He admits it gets him into trouble.

Visa & Ishita. These 2 gals are our QA contingent. Visa is a firecracker. Ishita is very determined. Just this week I was explaining how something worked, and Ishita hung in there and challenged me on it. I can appreciate that.

We are fortunate to have each one of them!

I got lucky on the last day

On the very last day, I hired our Java team lead. I really got a good one. He is cut from mentor cloth. He wants to "own" the team, but he wants to grow them. He wants them all to succeed. I'm fortunate to have someone with good character in this position.

Training

Training was pretty straightforward. They all got it. I couldn't believe how quick they took it all in. I had always been told that in Indian culture you have to be careful that they will claim to have understood something that they don't understand. They REALLY don't want to disappoint. We've seen this over and over again in a good way - in that they do not want to miss deadlines. They are happy to work all sorts of hours provided you simply appreciate it.

How are they working out?

Now we're a few months into using the team. We have a status call every day and go over what they are to be working on, and what they accomplished. We do this at 8:30 EST, which is 7PM Bangalore time. It takes about 30 minutes out over every day. It's a status call as well as a social outlet. We want them to continue to feel like part of the team. As of right now they are slightly ahead of schedule on our next release, so we'll be able to address a few additional things at the end extra.

But how did it save my job?

Going into the trip, I wanted to quit - I really wanted to quit. But I really like this team we've assembled. Not even the team, but every individual on it. I wish them all the success in the world.

Getting caught up - how did the "agile experiment" work out?

2008-10-08T21:57:00.006-04:00

For a while, blogging was a craze. Blogs are hard to keep up with, but at this point it's important at least for me to journal what goes on. So much has changed in the last year, I don't know where to begin - so I'll just try to pick up where I left off. A flury of posts to follow.

As a team we've morphed our processes to something that resembles Agile/scrum. Changing development processes is so disruptive, because it really takes a lot for your entire expanded team to get on board. There was a lot of interest, and (almost) everyone on the team was a willing participant.

It was tough not having an experienced "coach"/"scrum master" on board. We (Simon King and I) relied heavily on what we took away from David Hussman's lectures from NFJS. I got some real help in the form of our QA Lead later in the year, when she was able to attend Agile (?) in Washington D.C. She and another QA analyst came back renewed, at a time when I was "hitting the wall" and getting tired of carrying that particular ball. She has introduced at agile management tool, VersionOne, which I'm sure I'll touch on later.

In the meantime, Simon, who was my development manager - got promoted! For a while we were marching along, but running out of gas.

I have to hand it to Barbara though. Of all the people I really expected to let it regress to what we were doing before - she stuck to it, and continues to stick to agile.

Again, we had a fairly lightweight waterfall-like process that worked pretty well, so it's not like people were going after our process with torches and pitchforks... Moving to agile was a huge business risk because we were moving to a process we had zero experience with. Barbara's been a tremendous help to me, helping me transition from a development role to more of a development manager role. On top of all of that, she's a good friend. Her advice means more to me than anyone else at the office.

Have we gotten better at agile?

We have become more confident in agile. I'm not talking about in the sense of reaping all of the benefits that agile has to offer a development group. I simple mean with respect to the mechanics of carrying out the process. I'm pleased that it lived this long.

So How Do We Do Agile?

We are sizing User Stories with story points (out story points are $ amounts). We do release planning based on an overall dollar amount of work we expect to get done. A $1 amount represents about a man-week for us, based on what a Sr. Developer expects that a moderately experienced developer could get done in a week. We then estimate features by giving them a $ amount of $1-$10, and then pack a release full of features in priority order. We're always working on the highest priority item throughout the release.

Next, we break out the release into some number of iterations - typically 8 2-week iterations, plus some extra time at the end for QA integration testing. I'll assign the features to iterations, and then develoment resources to particular features during the iteration. I like to have pair-programming so we have 2 people responsible for any particular part. It tends to keep the ball moving down the field.

Each feature is broken out into User Stories, each given a MoSCoW rating of priority. Each story is given tasks that it will take to complete them. Our latest accomplishment is bundling of Stories and Tasks together into what we are calling "testable units". Once a developer has something build-worthy, we let QA know and they cut a new software build from whatever source countrol branch the feature is developed on. This is working particularly well, helping solve the issue of QA getting jammed for time at the end of a release. In order to support this though, we've gone to a more agressive branching strategy, making more feature branches - merging down to the trunk when we commit to shipping them (fixing any defects found at that point directly in the trunk, as the feature branch is closed).

Hmmm what else... Well, there are things we are doing that are NOT agile. I'll cover those in another post.

Agile Adoption (the story so far)

2007-11-25T23:46:00.002-05:00

We have been introducing Agile development techniques to our development group over teh last few months. This includes product management, business analysts, QA, and development members.

Adoption I believe has been slow but successful. The main reason for this has been that our existing waterfall-like process really wasn't that bad. We had over the years come up with good documentation that were an appropriate level of process and documentation to be meaningful. I think there is some don't-rock-the-boat mindset, but even those people have been more engaged in this than I would have ever imagined.

So if our process "worked", why even look at agile?

We needed to investigate agile because we needed to be agile. Being a hosted web application, we have chosen the model that we release "small and often". While the level of specification has always been good, our lack of software team management often meant that deadlines were missed or project size mis-estimated. We are looking to add SCRUM techniques and iterations (with deliverables at the end of each iteration) to serve as milestones along the way. We need the agility to deliver larger projects in iterations. We need agility to help us to be able to quickly deliver code if needed. We need to be able to iteratively deliver features, so that we can respond as a team better to changing priorities. Agile will give us that. We have been able to implement a few mid-sized features this way, and it has been successful.

So what have we done so far?

For a given feature, we enlist a feature team that includes product management, development, QA, DBAs who a business analyst "pitches" the feature to. We're assuming that at this point it has been determined that there is a business need for this feature. The feature team meets and fleshes out user stories. These stories are weighed as far as relative complexity, and are broken down into sub-stories until they represent some reasonable set of scope. From the stories, developers create tasks which are grandular enough to put meaningful estimates on.

User stories are also categorized on a MoSCoW scale, meaning Must/Should/Could/Won't. I.e. relative priority. We want to make sure we get all of our "musts" done for a release.

We haven't really calculated developer velocity yet on an individual basis. We are using generic "half day of effort" to be a story point. We hold developer stand up meetings daily, where we should be tracking progress in terms of completed story points which can be tracked on a burndown chart. We haven't implemented this yet.

We have looked at developing personas and are interested in this as a group. We just have not made the time yet to develop meaningful ones. Again, this is a mature web product where we are on fist name basis with some of our key clients. One of our product's strengths is our teams' ability to respond to user enhancement requests. Because we are already intimate with several of our customers, we have not dedicated the time to build personas that represent them. I still believe it is worthwhile because it removes some of the personality of the individuals that we know from the roles that individual plays. Personas don't have to be flat and dull, but they should also not instigate any bad feelings or other baggage around interactions with a specific client individual.

I am encouraged.

I think my organization has adopted well the agile principles we've put forward. We are still amatures and feeling our way through the landscape. Also, we've stopped pushing new agile concepts for the time being as we digest the basics and become more familiar and trusting of them.

Adding Agility to a mature Java product.

2007-08-28T22:46:00.000-04:00

Having heard Dave Hussman give the lectures on Agility at the NFJF conference, my supervisor and I came back fired up to see how we could introduce it into our organization. I'm just now at the point where I can do some reading on the subject, and have a couple of resources that are a good read.

First, my supervisor handed me some printouts yesterday of a whitepaper entitled "Making Agility Stick", Cutter Benchmark Review, Vol 7, No. 7, July 2007. With that many sevens, how could it be bad? Actually, it's quite good. It has a contribution from N.C. State's own Laurie Williams, from the NCSU Laboratory fo Collaborative System Development, among others (but I have to hype the local talent!)

My point with this entry is to journal my experience introducing Agile into my organization. I'm a lead developer, so I have a peer relationship with my teammates - so I am really not at a position where I can mandate anything, I can only encourage. This is fine by me, it fits my leadership style.

As of today, I am not that familiar with agile development at all. I've experimented with XP in short bursts. My current officemate and I work well together in pair-programming situatiuons, but the activity is usually reserved for crisis emergency-fix situations. I know that the goal is smaller relases with rythm, incremental/iterative development that focuses on making progress "burning down" your stories in "sprints". Yep, that's all I know, and I don't know that I have even that correct. Laurie said in her article, "Agiliy is not an option - you just nee to determine how to go about being Agile." And with that, my study begins.

Agile is not a single methodology, but a category. The well known Agile methods are:

Extereme Programming (XP)
Crystal
Feature Driven Development (FDD)
Dynamic Systems Development Method (DSDM)
Adaptive Software Development (ASD)
Scrum

TODO: link those to synopses

My biggest suprise was not that there were multiple, but how little overlap there is among them.

Making Agility Stick

Having just read this whitepaper, I wanted to take down some impressions. I think these will be worthwhile to go back and review as we make progress. Here are some quotes from the articles that jumped out at me.

People involved in a change need to be able to answer the quesiton, "What's in it for me? (WIIFM). Within a single software organization, WIIFM is different for each role (tester, developer, architect, manager, director, CIO, etc), if not for each person. Depending on WIIFM, a person may initiate change or resist change." -Laurie Williams, Stickiness of Agility.

We need to find out what about Agile works for each role and make sure it is communicated clearly. Everyone needs to understand what their "win" is supposed to be, and then fire them up to deliver it.

Rather than the organization's goal being "Transition to Agile", you must set a concrete tangible busines goal. Position that goal to be most achievable through the use of Agile methods, shrouding the often-disdained software process transition with the emotion of striving for unexpected and unprecidented success. -Laurie Williams, Stickiness of Agility.

We don't currently have a big, high visibility feature that will unify across development. There are a few medium sized projects, so it would be interesting to see how can umbrella them ala Five Live. "Five Live" was a push where a company adopted an agressive goal where it probably couldn't be achieved without moving to an agile methodology.

I am a firm believer that the relentless focus on speed mitigates many of the risk sources of projects: scope creep, changing priorities, mounting technical and defect backlogs, lack of dedicated resources, and so on... The concept here is simple, the less you sign up to deliver in one release, the less there is that could go wrong.
-Sam Bayer, Seven Rules to Making Agility Stick

Agile touts the ability to deliver the right thing faster, and that quote sounds like a reasonable assertion to me. With all the focus on faster, as a developer (and probably QA would react similiarly) it sounds like it may begin to feel like a vicious-treadmill-of-death. What is built in (if anything) to help people not feel that way?

"Regardless of changing conditions throughout the project, the team would never be allowed to adjust it's initial estimates, which in reality become the defacto committments to the organization.

In my experience I guess the "allowed to" would manifest itself in that the developer felt like they couldn't take the time to stop what they are doing and totally re-estimate if necessary. First, it makes them feel like they look terrible. Second, most developers thing they are just another half-day from delivery all the time, so think that re-estimation would be pointless. Third, estimating software as a task is aweful, and is typically wrong anyway. It's hard to get over those feelings and do it.

Will Agile Stick?

How do we keep momentum in agile? I can already imagine people reverting to where they are comfortable. In our orgainization, that would be our current waterfall model. I think there is a bit of resistance to Agile because truly we have finally gotten the waterfall working relatively well, so I think there is perceived risk of fixing that whih isn't broken. I can understand that sentiment. We just have to communicate what they should expect to see as the ROI. You simply can't argue with ROI.

NFJS - No Fluff Just Stuff (Raleigh Marriott, July 2007)

2007-07-30T22:31:00.000-04:00

All I can say is that if you feel like you've been out of the Java development mainstream too long doing tasks for the Man, then this is the event for you.

No Fluff, Just Stuff

I really can't express how much I appreciate the lectures from those involved. I especially appreciated Dave Hussman's lectures on Agile, and David Gearys lectures on JSF/Spring/Ajax, and GWT introduction. There were typically 5-6 lectures going on concurrently, so you couldn't see everything. You could get the slides and source code though.

This is exactly what I needed to jumpstart me again after a busy Summer where I had been head's down coding. I'll definately be there next year. See you there.

If you can't be there, I STRONGLY recommend buying the NFJS Anthology Volume II which is a compilation of several of the lectures. It is very broad, covering:

New Stuff (GWT, Groovy, AJax techniques, REST)
Testing (Unit tests, Capistrano, FIT/FITness, continuous integration)
Agility

Great stuff.

SOA architecture, but just one endpoint please.

2007-05-17T09:00:00.000-04:00

I mentioned earlier that I work with a healthcare software company. In any EDI project, there is usually a common protocol involved, in healthcare that protocol is either HL7 or X12. The easiest way to speak those languages is to rely on an EDI mapping tool or "interface engine" to be your middleware.

There are several vendors out there that would love to sell you an interface engine, for the price of a garage full of Ferrari's. You can control the price some by limiting the number of endpoints through which you can send data to your app.

So now I have a project where my P2P path between our engine and our app will be thorough a single endpoint. Yay. So I have to build a hereIsEverythingFigureItOut() web service, in order to minimize the number of endpoints that we have to pay for in this quarter.

What's a boy to do?

As an architect, I am still compelled to do the right thing and build a proper API as it truly should be and let this assinine single entry point talk to an adapter class which tickles that API.

Addendum 8/27
Boy was I whiny that day... Sheesh. Sorry about that. The truth is that we did bring in the Rhapsody interface engine, which in its latest release is quite slick. I haven't had any hands-on time with it yet, as our senior analyst is hogging it (truthfully, I've been far too busy). As far as this project, we ended up not going with web services at all, but rather continued on with our legacy framework for the time being. Since then, I've been turned onto RESTful web services, which I'll have to do a post about at some point.

Tragedy hit Virginia Tech today.

2007-04-16T13:06:00.000-04:00

I sit at my keyboard in utter horror as this story unfolds. My prayers go out to all of the families involved. As an alumnus, you always want the best for you alma mater. I have no idea what this young man's situation is, but the thing that saddens me the most is that he though he had no alternatives.

My heart does swell with pride, in my watching of Hokie Nation banding together to support each other in a time when no one can make sense of the actions of that day.

Let's go Hokies!

HL7 v 3.0 is a little disappointing.

2007-02-09T12:10:00.000-05:00

I was disheartened to come across this post which describes other's difficult user experiences with HL7 v. 3.0. For those who do not know, HL7 is a well known protocol that heathcare providers user to interchange data. Ansi X12 is often mentioned in the same breath as HL7, if you're familiar with that one.

Well, the great thing about HL7v3 was that it was going from a character delimited format to XML. That would open it up to all sorts of benefits, such as schema validation, and much better parsing ability.

The (hospital) marketplace has been slow to adopt HL7v3, but software vendors are supporting it. It will only be a matter of time before we have critical mass. I just hope that my experience is better than the one referenced here.

On a positive note, I did email hl7.org about the availability of the open source eclipse plug-ins that are being developed for HL7v3. I received a nice email back from Richard Kavanagh himself (the development manager) indicating that they can be found on the Eclipse OHF site. I continue to watch the OHF and IHE projects with great interest.

Time flies when you're heads down coding.

2006-12-29T08:24:00.000-05:00

The point of this post is to "remember to make time for yourself". I remember reading 7Habits a long time ago, and I don't remember much about it at all - except this: Figure out where you want to go in life, and analyze if each action you take is bringing you closer or away from that goal. This principle can impact every little aspect of your life. From how long you decide to work for your current employer, to what you spend your time looking at while surfing at work. There are a ton of platitudes that come to mind "Aim for nothing, you'll hit it every time" blah blah, but they do all ring true - although they all leave that saccharin aftertaste.

Whenever you're head's down in a project, take time to reflect back about what you've learned, how you've grown, and what you want to learn from the experience. Don't let it be a waste of time for you. Just this instant my coding isn't exciting, so trying to integrate my development into myEclipse. I guess I'm the last person in java-land to start using it, hence the subtitle to this blog. It's a little thing I am doing while grinding out the mundane code that keeps me moving in the right direction.

The Consequences can be Fatal
Back in October, I lost a friend to burnout. He's ok, but he got himself fired. He had a lot of things going on in his life (family health), and he went dark here at work. From my perspective he could have handled it all better - but this comes from someone who wasn't in the situation at all. I tried to help him right the boat a few times, but his heart just wasn't in it. I still think we could have saved him, but others saw fit to let him go.

I have another friend of mine who is going through a divorce, and he is always out loud reminding himself "I've got to get a move-on!". It's been powerful to hear - it keeps me thinking about what I need to be doing.

So, what have I been doing? I have had several work projects going on. I've written an XML interface to Maryland Hospital Association to send CMS quality initiative data. If hospitals participate in a current quality initiative program that CMS is running, and they score well against the criteria, they can receive an additional 2% reimbursement. This is a huge stack of cheese for hospitals, especially since they typically lose money on Medicare patients. That qi link is to Premier. Earlier in the year I created an interface to their site for the same program.

[rant]
In both of these interface development efforts, we were unable to have either Premier or MHA develop proper interface endpoints for our software. In both cases I was left to write HTTP browsing clients to navigate their web sites and initiate a file upload. So, the reliability of these interfaces is impacted by the very structure of their web sites.
[/rant]

[rave]
Thank God there was HttpClient out in the opensource community. Implementing that rant above took just a few hours because someone released a solid, well documented library. Yay Jakarta Commons!
[/rave]

I've also been working toward replacing our internally written ADT code with an interface engine. We are looking at Rhapsody. We had a WebEx session with them, and I was quite impressed. The interface is very intuitive, and I expect if we purchase it, it won't be long until we are live in production. That is my hope anyway.

Not only will this replace code that we've had to maintain, but it will open up other opportunitites (such as web services) so that we can uncouple our ADT from our main JVM. We're going to create an inbound Orders interface as a test project for the engine integration. Hopefully I will have schedule to do web services as well.

Some things are worth repeating.

2006-08-30T10:55:00.000-04:00

I just got pn3d. Recall back on May 10th when I said "know your specs"? I just got caught out because I didn't know them. In this case it was the HTML 4.01 spec.

I've been implementing an interface where the client has refused to make any accomidating code changes. Therefore, I'm left to use jakarta's HttpClient class to navigate their site and perform a multipart post to submit a file. I had been screwing around with HttpClient, and had convinced myself I just wasn't using it correctly (though my code matched their example almost verbatim).

My issue? I was posting the login/password params sure enough, but you must also post the submit input name and value. Really? I wouldn't have expected that, but it's in the spec (See: Successful Controls).

What is a database, exactly?

2006-08-14T15:11:00.000-04:00

Ok, we all know that "data" goes in the database, but what about code?

I think we all have a basic understanding of what a database is, so why do I ask? Well, we recently got into a discussion as to the role of the database in our web application. Some say that a DBMS is a highly tunable entity that is an expert at sorting through vast amounts of data. Others say that when writing an application, you should not write many stored procedures, becasuse you end up becoming died to the vendor's flavor of SQL.

I can certainly understand the merits of wanting no not tie yourself too closely to any vendor's anything. However, w.r.t. a DMBS - the investment is so large to get it, and the paybacks can be so large, that I now truly believe that all of the features that you have paid for should be exploited. Companies do not change DBMS's like people change underwear. It's a long term - high dollar investment, and I think you're just foolish if you don't maximise the return.

In my case, our software runs on Oracle. However, our data is manipulated through lovingly crafted SQL in java dispatched via JDBC. No stored procs here, or very few anyway.

It's killing us.

I'm not a DBA, but I know what SELECT does...

Do you? I didn't. Not really. I just finished the most enlightening 30 minutes I ever spent reading about databases (Oracle 9i in my case) came from Effective Oracle by Design: Chapter 5, Statement Processing. Anyone familiar with AskTom knows who Tom Kyte is. In this particular chapter, he goes over the phases of statement processing.

As boring as that sounds, it is tremendously important. This gets at the very heart of our own DB performance problems. The way we've written the application, we hard parse every statement. Don't dismiss this as a simple "cache miss" scenerio - that's what I thought it was. It's much worse than that!

Each time Oracle gets a statement to process, it must

validate it syntatically,

validate it with respect to other objects (can it view the tables/data is is asking for?)

validate it with respect to the oracle environment.

generate the code

optimize the query

stuff the statement in the SGA

Now, it can execute the statement. Imagine how fast your code would be if it had to compile/link a class every time it ran? That's basically what a hard parse implies.

What is my point exactly? Well, that I didn't know what was going on - and had I known we could have been addressing this years earlier.

Always read.

2006-07-24T17:22:00.000-04:00

Always be reading. It is the single most important thing you can do to both and improve your game and improve your income.

In 1996 when I graduated from college and got my first salaried job, I met a contractor named Scott. For whatever reason, he took interest in me and among other gems, gave me the above advice. We were on a DoD project coding a large system in C++. Scott had referred me to nearly a dozen books that were "must reads" in the field. Here's a sample of them (I still remember these to this day):

Code Complete by Steve McConnell
OO Analysis and Design by Grady Booch
Design Patterns by GoF
Effective C++ / More Effective C++ by Scott Meyers
C++ How to Program by Harvey & Paul Deitel

I'm not going to go on about how I became the project architect overnight. What I will say is that I bought and read all of the above books. In just a few months I went from a "new grad" to hanging in there with contractors who had been in the game a while. My stock went way up. Management wanted to keep me around. Because of my 140 I.Q.? Hardly. More becasue I gave a damn about what I was doing, and it showed through my personal growth.

Read good books.
I'm not talking about how books - the 900 page tomes addressing Ruby on Rails. I am talking more about why books. Books such as these have really made a huge difference in the quality of my code.

Any of Martin Fower's Signature Series books

Object-Oriented Software Construction by Bertrand Meyer

Software Project Survival Guide by Steve McConnell

These are not "new" books. These are especially good to reference when prepping for interviews. There is just so much good material in there.

Do I practice what I preach? I sure do. My current deskside reference is from the Fowler signature series - "Refactoring to Patterns". It's great stuff.

Analizing technology pairings - Ajax and JMS

2006-07-24T12:09:00.000-04:00

I recently read this proposal for Ajax/JMS event queueing and I have to say I initially like the idea of the technology pairing. So how would I evaluate it?

As the author has responded in the TSS blogs, this does not necessarily need to be JMS. The undelying thought is still sound - to combine AJAX communication events to another publisher-subscriber framework where others subscribe. It's a great way to decouple the UI from the middle tier. It actually decouples the middle tier API from the requests.

Would it be performant? That seems to be a chief concern, especially when bundling with JMS. However, I really think it could be, if you set it up correctly. Thoughts that come to mind are having prioritized messages - one for things that need to be snappy, and another for longer running asynchronous requests. I'm sure there are tons of strategies in the JMS community to get the performance that is required.

But why do it? Is there a better way? Where is the "win"?

Pros

Well, any time you introduce an event queue, you tend to get a defacto throttling mechanism built in. Your even queue simply expands if the server falls behind, rather than performance being killed across the board.
Adding an event queue also makes it very flexible to add event consumers, in that you just register other interested parties in the topic. I can see the utility in this too.
If you already have JMS messaging in place - that would certainly leverage existing JMS expertise and codebase, which itself has a very simple and natural API.

Cons

It seems like utilizing AJAX to call web services directly could be just as flexible. This would allow both the UI and third parties to exercise the same API. A limitation to calling web services is the security issue where you can only communicate with your request's originating domain. Therefore, if your services client is external to you, then you need to proxy the service request on your server.

If you don't have JMS in place, then there will certainly be some care and feeding of those components as technology moves forward. And there will be development costs to getting familiar with the framework.

This bumps Ajax in Action to the top of my reading queue.

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

2006-05-17T07:16:00.000-04:00

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.

2006-05-15T12:29:00.000-04:00

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...

2006-05-10T14:44:00.000-04:00

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.

Java - where are you going?

2006-04-25T15:19:00.000-04:00

I am a Java developer by trade. More specifically, a J2EE developer. Slowly, we are moving over to JSF development, and are looking for ways to blend AJAX into our app. I personally focus on middleware - and fortunately it appears that the healthcare market is screwed up enough that I could probably make a career out of it. That's the short term plan anyway.

Today, Scott McNeally (whenever I hear his name I think of Mr. McFeely - I guess the names sound similiar enough)- well, Scott stepped aside as CEO of Sun Microsystems. What does this mean for Java? The jury is still out. It looks as if the new guy will be more bottom line focused - and if that saves the company then that can't be all bad for Java (crosses fingers).

On a related note, I don't know where Java is headed, but I do know where jobs are. I came across that book from the Pagmatic Programmer site. It looks like I need to work on my defense a bit. A co-worker reminded me how much my current employer relies on outsourced development.

Edited 05/10/2006
I found this on Joel's site:

Here's something Pradeep Singh taught me today: if only 20% of your staff is programmers, and you can save 50% on salary by outsourcing programmers to India, well, how much of a competitive advantage are you really going to get out of that 10% savings?

w00t!

Welcome

2006-04-20T14:03:00.002-04:00

Hey, welcome to my blog. It's more of a personal notepad really. I'm going to keep it professional - by which I mean J2EE software development.

This is the tale of a developer that's been "head's down" coding. Now that I have raised my head, I no longer recognize any landmarks. I am a man lost in the Java wilderness...

Ok, that sounds a little more dramatic than it really is. Maintaining this page is a challenge to myself to stay current in the field.

I've yet to work on a project where the powers that be cared if we were on the latest release of anything - or if we were using the most current frameworks, etc. Nor have I ever had a boss come and tell me to re-architect the product because it was fragile, it wasn't flexible, -or- they were concerned about my skills getting rusty. All of this falls onto our personal responsibility. We should be going out and keeping ourselves current, sharp, and dedicated. Otherwise, you may end up where I have found myself today. However, next year I won't have this problem. Will you?

Careful there fellow code-monkey, it could happen to you too.