Bring on the Balkanization!

For years now we've been told about the benefits of combining functionality in an effort to do more with less. This has been especially common in the world of software development where once scattered systems now fall under the umbrella of a single system. Generally, this has meant greater functionality at a lower price. I myself have done this with various web components albeit on a much smaller scale. This trend is referred to as Walmartization and socioeconomic considerations aside, it will continue to have a large impact on software development for some time to come.

Yet despite the good intentions companies may have in providing an all-in-one solution, there are some things that simply cannot be predicted as a need when developing the software. More of a hinderance still, they cannot engineer a product so generalized as to allow somebody to easily add powerful features without requiring a basic knowledge of information sciences. The closest I've seen to this laudable goal is the Google Mini which utilizes XSLT so that a customer can render their results however they'd like.

Reality does not seem to faze large software companies though, or the managers with large budgets who purchase from them. Case in point, I am currently at an impasse with management over the direction of our customer portal. While I fully believe that an integrated back end is a great idea, I also feel that our front end should be controlled by us. The customization that has gone into our current product in just over a year is extreme and to expect a vendor to match it would be overreaching to say the least. Not to mention that we are at the whim of our marketing department which expects changes in days, not the months-long timescale vendors commonly adhere to.

For this reason I say bring on the Balkanization! One piece of software shouldn't do everything. Some tasks are just too specialized to incorporate into a product meant for widespread use. Add onto that the fact that IT organizations often serve departments which expect changes quickly and you can see why such control would be better placed in-house.

Mid-week happenings

My Dad arrived in Melbourne yesterday though not for familial reasons. Strangely enough, he is here for meetings with my former employer. So far he hasn't run into anybody on campus that I knew but then a lot of them have quit since I was there. We've managed to go out to dinner every night he's been here and that's saying a lot considering how busy I've been. This was definitely not the best of weeks to show up but I've got to play the hand I've been dealt and I'm super happy to have him here. I just wish we could spend more time together.

The theater is where I've been spending the majority of my time lately. I volunteer at the Henegar Center in downtown Melbourne and our latest show Once Upon a Mattress has proven to be quite taxing from a technical standpoint. I am running the lightboard while also calling the show and though we are still in rehearsal, it is fairly stressful. For instance, I thought everything was going along swimmingly when I walked into the booth this evening but as it turns out, Hell was just about to be unleashed. From burnt out lights to messed up cues, it was a miracle we even got through the first act. Tomorrow is our last rehearsal so it had better be as close to perfect as possible.

On the work front I am busier than ever. I finalized the demo product today and begin working heavily on the presentation materials. Everybody who has seen the demo in action agrees that even in its nascent state it far surpasses our current version in every category. This is probably the first project where I can truly feel I have relied on others' expertise. So regardless of how management views it, I know that I will be able to take something positive away from this experience.

New York Mets vs. Washington Nationals

On March 15th, 2006 I accompanied my fellow employees to a match of wits and strength between the New York Mets and the Washington Nationals, formerly known as the Montreal Expos. This has been a yearly event for the organization although this was the first year my particular department was invited.

This turned out to be a real learning experience for me. Firstly, I learned just what the limits of my new camera phone were. But more importantly, I gained valueable insight from my co-workers that would not be so easily accessible at work. As it turns out, several people have put faith in my design for a new web portal and are rooting for my success.

More importantly though, it has become clear that there are many opportunities out there for an IT worker such as myself. I have always managed to inadvertently pick fights with my most immediate supervisor and this organization is no different. My vision for the future differs from management's and I believe mine to be the correct one. I hope to persuade my bosses of the same yet the knowledge that there are companies out there that desire a new and efficient solution has given me a confidence that I haven't felt before. I have no intention of leaving my current organization but it makes me feel better to know that other opportunities exist.

In the meantime, please enjoy the impromptu gallery I have put together. This is my first time using Blogger in conjunction with my cell phone to create one but I think it will more than suffice.

Nothing personal, it's just business

So for the past three weeks I have been working my tail off to do by myself in Ruby on Rails what took my predecessors years to do in J2EE. That is, rewrite my company's web portal, albeit only a portion of it, which will be shown at a demo. Thanks to Rails' fully featured stack and the wonderful simpleness that is Ruby, I'm nearly done. The hard part has been getting some of the team members to get their tasks done. They're not lazy, they are in fact very hard workers but they are absolutely swamped with other stuff and this is at the bottom of their priority list. I'm quickly finding out that managing a project and doing just the programming as I am accustomed to are two very different things.

Sometimes I wonder if all this hard work is really worth it. Only a month ago management was touting my proposal as the panacea to their problems. Costing only $15,000 and taking less than six months to complete looked very appealing. Of course, the more conservative members of the corporate IT team didn't think it could be done, hence the reason for this one month frenzy of coding to get a working demo out there.

Yet while I'm performing this Herculean task, management is actively seeking external solutions, i.e. vendors. Ugh, the "V" word. It's not that I hate vendors per se, that's too strong a word. It's just that they tend to promise the world and rarely deliver on it yet get away with charging an outrageous sum of money. Colleagues with more experience in the industry than I have tried to explain it using terms like "mitigating risk", "outsourcing experience", and "long term management". But when a product costs 100 times more (that is not an exaggeration in this case) , won't be delivered for at least a year and has little to no customization available, it really makes you wonder what sort of solution management is looking for.

On the plus side though, it's good to know a manager and their fiscal year's budget are so easily parted. It ensures that the smartest workers of this country's growing knowledge-based economy will always have gainful employment provided they charge the "right" price.

Stepping over the stones

Yesterday I headed on up to what's affectionately referred to as the Business Center. It's where a lot of our hardware is located and also serves as offices for some of my colleagues who aren't quite in the same organization as me yet I have to deal with them regardless. They're nice enough folk but their mindset is a bit different than ours. They would argue that we don't necessarily "get" the grand plan while we would counter that our direct interaction with customers, as opposed to just fellow employees, doesn't allow us such a luxury.

So in the bi-weekly meeting that I attend up there I dropped the bombshell that I was planning on using Ruby on Rails in the rewrite of our web portal. Now understand that our current version, which was written before I started working there, is nowhere near what was promised to upper management in terms of capability and speed. Add onto that the enormous costs and the fact that the final product still hasn't been delivered and you can see how the people I answer to would be a bit anxious to get something rolling.

But naturally my colleagues didn't see it that way. Immediately a furor was raised over how I was going against the ingrained standards of the company and how difficult it would be to support an application written in an "alien" language. They made it seem as if it was Sean vs. The Holy J2EE Standard. Regardless, I know that the way to get Ruby through the system is not with direct confrontation. I did plenty of that at my last job and would much prefer to build bridges here. So I'm going the other route: I'm gonna charm 'em.

Upon return to the sanctuary of my cube I immediately set about creating accounts on my Linux box for each of those programmers who raised an objection. I then gathered all the helpful tutorials and links that I used when I was learning Ruby on Rails and put all the information into a nicely formatted, kindly worded email. The idea is that once they see the true power of this amazing framework they will better understand why I am going this route. I don't expect to make converts out of them overnight but I do hope that they drop their blind reluctance to it and give it the chance it deserves.

The cutting-edge and its place in production environments

The software developer constantly balances on the tip of a sword in their daily job. On the one hand they need to write production-quality applications in an efficient manner. But on the other hand, new tools and products are coming out every day that can help developers speed up their coding and also make their projects that much better.

These new tools however are not always ready for the production environment. I am especially wary of relying on products that are not v1.0 yet. But even those tools that are supposedly mature can introduce an untold number of bugs. When my former employer decided to go from ColdFusion 5.x to MX 6.0, the number of bugs doubled overnight. What had once worked in the old version, such as loosely-typed date formatting, no longer worked in the Java-powered strictly-typed 6.0. A minor revision a few months later helped in some places yet caused even worse bugs in others. But because in that few months time we had written applications that took advantage of all the new features there was just no going back.

In retrospect it was a good decision to upgrade however, certain steps should have been taken beforehand to analyze what changes a major upgrade would bring. This is why it is so important to have both a testing and development server in addition to a production server. With both of these tools we could have continued to develop in ColdFusion 5 while testing version 6 on a limited basis. When we made the switch to version 7, much more precaution was taken and though I was no longer employed there to see the final push I can only hope that the extra servers helped ease the transition.

Currently I am toying with the idea of using Ruby on Rails as the platform on which to build the next incarnation of my company's health portal. Whereas the accepted standard at the company is J2EE, recent articles have convinced me that the Ruby path is the true path though it may be harder in the short term with regards to management. In actuality, management at my company is fairly progressive and has never given me reason to think that they doubt in their programmers' abilities. And now that Rails is approaching the big 1, it will make adoption of it as an enterprise-capable platform that much easier.

Do not be afraid of something simply because it is new. The future is coming regardless of how we feel about it. Just as Java was once at the forefront of web application development, so I believe that Ruby is in that position today. But before you make that leap to a new technology make sure you have your contingency plan in order and are ready to put in some long hours if necessary.

Assumptions and their impact on software development

The rhetoric we usually hear about assumptions is that they "make an ass out of you and me". But I've heard another one that I think is more fitting in a lot of circumstances: assumptions are the mother of all fuck ups. This was proven beyond a doubt today when a vendor professed to us in a meeting that he had made certain assumptions about our product and that he would now need much more time to take these new 'facts' into account.

It's funny the way facts and assumptions work. For most, an assumption is a fact until it is proven otherwise. This is especially true in software design where there are so many variables that to take them all into account can cost an exorbitant amount of time. As such, programmers tend to focus only on the big ones leaving the smaller assumptions to sort themselves out. This can and often does spell disaster for large projects.

One of the ways to help minimize such dangers, besides increased communication between team members, is to decrease the complexity of a project. Remarkable advances have been made in software development to facilitate code testing without sacrificing budget, time or scope. On the Java side, I've been hearing great things about JUnit from my friends. But unfortunately for J2EE development, overall complexity still remains a huge hurdle to overcome, even for small to mid-sized projects.

Enter Ruby on Rails. This is the most ambitious project I've seen to date to try to tackle the problem of increasing complexity and overhead with regards to web application development. I've worked in many languages over the years: Perl, ColdFusion, PHP and Java just to name a few. When I saw what Ruby was capable of I didn't believe my eyes. But after I installed it and had a web application running in under 15 minutes, I knew that this was something big.

So many of the modern web application languages available today require assumptions to be made. Configuration settings, typically stored in large and difficult to read XML files, are assumed to be static but RoR makes no such assumptions. Using inspection and reflection, Ruby can change its configuration settings at runtime so that changes made to a database structure are promulgated to the application itself without having to do the reconfigure, recompile and redeploy dance so many J2EE folks have gotten used to. And most important of all, less assumptions equals less fuck ups.

Today is the first day of the rest of my web development life. I had two books waiting for me when I got home and I can hardly wait to crack them open. So after I sign off here I'm off to dive into my new RoR books. Look for more articles here on this subject as I learn about this amazing new framework.