Friday, October 07, 2005

Choosing the "Right" technology

About a year ago our company switched from a homegrown web model to WebWork. Through that time we have tweaked patterns used throughout the application. At this point we still do not feel as though we know and understand WebWork and XWork to their full extent. One of the core issues we have found is we chase technology too often and never get comfortable with what we have. No one likes to fall behind the curve but when producing a software product it is also very costly to change developer patterns continuously.

We have now started down the route of an external Apps Arch review and Spring has reared its head. We have been fans f Spring but have held off the bandwagon largely because it is more change. We do use it in some very targeted services, built by a specialist team, but have not introduced it into our core application.

Being a technical person I struggle with choosing the best technology as opposed to what is right given current resources, past problems and business goals. The easy answer people give is to simply bring it in slowly on new functionality. While that is good once doing that over and over gives you a "quilted" application. Depending on what square you are working on you have to figure out what you are doing. Webwork or homegrown, today's design patterns or yesterdays, spring or not.

Though choice is good - it can also be a real pain in the ass.

Sunday, October 02, 2005

Groupware, Information Transparency & Team Building

The development team I work with is divided between two states. We make a valiant effort at times to feel like one team but we rarely achieve that well oiled machine feel. A couple of years ago we tried to cobble together an information sharing network (maven generated site with added forum, blog\announcement page and standards documentation). This got us absolutely nowhere as those most familiar with information and use these sites in the open-source world were our only users while those we were trying to help didn't ever really participate. We always fell back to email and IM with people missing out on all the real information sharing in the hallways.

We are charging back into this world once again. I hope this isn't another of our build the tools and people will come exercises. After doing some research we have decided to go with Drupal, a full CMS implementation. Our goal is that involving others beyond the engineers will help integrate this into our daily lives a bit better. At the very least it has given me a reason to play with PHP in the context of a real goal - though I would have preferred to play with Ruby and ROR (but as the new kids on the block there isn't a CMS that comes close to the PHP variety).

I hope this works. Lack of communication is one of the key reason we struggle producing software. Maybe something to do with the lack of requirements too - but that leaves tons of room for "creativity". If it doesn't work - I say we make the other office move to Dallas.

Attracting Talent

The little startup that is semi grown-up now is having an interesting problem. When you finally learn from your mistakes (underestimating the people\effort required, focusing too much on the future, hiring cheaper employees, etc..) how do you attract new talent. We are no longer a startup that can offer a true sense of ownership, nor are we a large company with lots of money to play with the latest toys and also though I still find web development challenging we are essentially building decade old technologies (no Web 2.0 here). We simply have a lot of hard problems that require talented people who enjoy bringing a bit of order to some chaos. Those engineers and managers we want to hire, don't seem to find us an interesting challenge so we are left with salary being our only leverage. Though money is nice it isn't the be all end all especially when hiring roles that would pay good money regardless. So we are almost in a catch-22. Do we hire people less qualified than what we wanted (essentially against what our hard earned lessons taught us) or do we wait forever and continue to screw things up in the meantime.

I guess this has all been a lesson to do things right the first time around. It is a hell of a lot harder fixing a company than it is to set it out on the right foot.

And the kicker to the whole thing is, how do you attract this talent\provide offers that won't end up pissing off those employees that took you a long way in the first place.

Next time around I am taking Joel on Software's advice and hiring the most talented people I can find and to hell with what others think. I would rather have 5 amazing people than 15 average people.