Tuesday, September 9, 2008

Grails, Rails, and Java

I recently had an opportunity to work with Grails, Rails, and Java to solve some similar internal business problems. Dynamic languages are great productivity enhancers for a very small team of highly competent experts in the field. However, in the hands of an average programmer without rigorous guidance and careful review they should be classified as weapons of mass destruction.

While I haven't yet tried this with Rails, I did make a recommendation (after using it myself) that we switch some of our simpler new CRUD applications to use grails. Heck, why screw around manually wiring in spring/hibernate/etc when you can use grails and get all kinds of neat things for free?

The first problem we're struggling with in grails is that there are some cool and super ways to get things done, but because we can always revert to java, most people just do it the "java way". This means we've forsaken the safety of compile time checking and gained ... nothing.

The second problem is that, even if one decides to forage into the groovy/grails way of doing things, there is more than one way to do it^4 and our code begins to look a lot like hacked together perl modules. The newness of the language is a pitfall for folks who absolutly require it to have been done before

Sunday, July 20, 2008

Google App Engine

I just took a look at Google app engine. I wrote a quick dirt CRUD application to see what it's all about. It can be found at http://findmysport.appspot.com/. What amazes me is that it is python based...

I wonder why google uses python so extensively. I've used it for a number of things and find it very useful, but it just doesn't seem to have the momentum in corporate america of the "big J". On the other hand, it has tremendous street cred and is embedded in tons of open source tools.

I found an interesting writeup here: Python at Google (Greg Stein - SDForum) it looks like google architects from the ground up and the guys on the ground said "python works for us".

Saturday, July 5, 2008


What's with portals? It seems like this is another "flash in the pan" technology that many people jumped into without any idea of how/why to use it. We're looking at using a portal to provide some web UI templating and document management, but we're finding the reuse potential of even a JSR168 portal is hampered by legacy technologies.

The exciting thing is the ability of portlets to communicate with each other, the down side seems to be this is not a core portal capability (certainly not from a client side perspective). Some interesting reads are:

This latter link is a better statement of my problem.

Sunday, June 22, 2008

Architectural Thinking

I just had the pleasure of attending a 3 day "crash course" architectural thinking class. This was sponsored by my company and facilitated by architects from a large and successful consulting company.

It was very interesting to see the perspective of the consultants who taught the class. The material was very relevant and the discussions with my peers in our organization where good. By the middle of day two I really began to question the point of the class. Much of what was discussed was very necessary for a consulting organization and I would argue has value in any IT department, but I'm not sure it was solving problems we need solved.

In discussion after the class, one major problem we need to address is what I call the "road to nowhere" problem. We're furiously building solutions, setting standards, generally doing a bang-up job getting things done; but we're not sure where we're going or worse yet, if anyone else is going to want to go there also. Adding to the problem, we are not sharing our findings with our peers (or are doing it inconsistently) so we're solving the same problems over and over again.

I've started making noise about getting serious about our document management and information organization. We cannot be successful without this and it is much more fundamental than "architectural thinking".

Tuesday, May 13, 2008

The Agile Development Process

Software development in bigger shops is getting more complicated due to the movement toward agile processes. Management often seems to think "oh great, I can deliver more product faster" without getting rid of any of the overhead their old process incurred.

So now we have a situation where we have an 80 hour development effort saddled with 20 hours of meetings, status reports, use case writeups, blah blah blah. None of which is actually used for actual development and none of which enhances the interaction with the customer. There is a sore need to bring the agile process into the fold of SDLC and start espousing that Agile IS SDLC, just a different version from waterfall.

Friday, May 9, 2008

Corporate Open Source Software

Why do many corporations insist on reinventing the wheel?

I recently proposed we open source some software we are writing. I did this it's a pretty cool concept and we cannot afford any developers. I went and spoke with a few of my cohorts at other companies and they thought it would be a cool project to work on, but our company cannot currently afford to pay these folks.

Hmmmm, what to do? I know! we'll make the core infrastructure of the project open-source.... perhaps get a free version of Jira/confluence and start building a communnity around it.

This has the benefit of getting some (potentially) high quality developers to work in it for free, and additionally if I leave, I get to use this software at my new location. From my employers perspective, they will still get fixes after I leave (it's open source, everyone will right?). This sounds like such a win win win situation that I was excited to share this idea with my team.

Needless to say it did not fly well and a somewhat blank stare was about all I got. I see it will take some more wrangling to drum up support for this, there was not a huge amount of support for the concept.

Monday, May 5, 2008

Wasted compute cycles running screen savers

In the spirit of the SETI project, I'm asking myself again... Why do we spend money for really expensive machines that spend over 1/2 their time rendering whiz bang screen savers? A company could make a killing with a distributed agent that used those cycles to solve business problems instead of displaying a screen saver.

Tuesday, April 29, 2008

Be on time for meetings

We recently had a team meeting where we discussed how important it is to be on time for meetings. A comment was made that "It's disrespectful to be late for meetings".

As a prime offender, I kept my mouth shut, but certainly had a few pointed questions I really wanted to ask. It's great to SAY we should all be on time for every meeting, and we should respect everyone's opinion, but DOING that is a little more problematic.
In the past, I personally had an average of about 3 hours of meetings per day. These were recurring, scheduled meetings, that I typically sat in and listened to other people talk. Truly there was probably about 2 hours of meetings per week that I actually had conversations and constructive/useful information that was communicated.

I actually think the problem should be turned around and we should make sure that meetings are useful. To me, a 1 way dissemination of information is best served by an email message. Meetings should be reserved for face to face interactive discussions. If you routinely have to say "we don't have time to talk about that right now" then you probably don't need a meeting because you don't want a discussion, you simply want to dispense with information or instructions.

Monday, April 28, 2008

Grand theft childhood

I saw an interesting article about violence and video games and their impact on children. There is evidently a book called "Grand Theft Childhood" that examines this.

I might have to take a look.

Sunday, April 27, 2008

Hammers and Screws again

I had an interesting situation back in January. I was called into a last minute minute meeting and asked to explain why I thought we needed JBoss and why websphere wasn't OK.

Frankly, I was stunned. I was told the meeting was to discuss what sort of hardware we needed and where it was going to be deployed.... Suddenly I'm asked to justify using JBoss instead of websphere to a bunch of fairly skeptical folks who where VERY interested in using websphere at all costs (for some reason).

Well, I stammered and stumbled since I wasn't really prepared to answer this and I could almost hear the folks on the other end of the call tapping their fingers on the table, waiting expectantly for my answer for them to instantly debunk.

I stopped for a full minute, my entire mind switching gears from "what sort of hardware/capacity might we need" to "why do you want to use JBoss instead of Websphere".

I then proposed the obvious thing (to me) "Well, Jboss is free".

Of course this was a ridiculous reason for using software. I was promptly schooled on how we would NEVER, EVER deploy FREE software, we absolutely MUST pay for it. After all, who would support it?

So I was a little bit shaken (not stirred) and had to think about it. To me, it is really great to be able to actually diagnose production problems by looking at the source code and figure out what went wrong. Most closed source companies don't really like you doing that (unless you pay them a WHOLE LOT of money).

Xn= kXn-1(1-Xn-1)

It's interesting how things just sometimes go "click". I was perusing the net reading about various topics on software development and business management and stumbled across an interesting paper discussing disaster response (I think it's actually referred to on the agile wikipedia entry) What Disaster Response Management Can Learn From Chaos Theory

This paper goes into some depth explaining how nonlinear functions can be used to analyze disaster response. I got increasingly interested as I realized that, in some ways, information technology has parallels to disaster response. More importantly, nonlinear math has a huge potential to help analyze and solve many information technology problems.

I did a little more research and stumbled upon this gem and began reading it:

Organizations and Chaos: Defining the Methods of Nonlinear Management
Book by H. Richard Priesmeyer; Quorum Books, 1992. 258 pgs.

This is written by the same person who did the disaster response paper and is a compelling read. The reason it's so interesting to me is that these problems have exact correlations to many problems I see with software development. For now, I'm going to finish this book and I'll follow up later with some 3/4 baked ideas.

Friday, February 8, 2008

Why use a wiki?

We're moving toward collaborating more and more via a wiki than attaching word documents to email messages. Our belief is that this will allow us reduce the number of stale copies of documentation. In addition, we instantly get an up to date revision history and email notification when people change things.

We've seen some pushback from people who seem to think that they always know exactly what is going on, so there's nothing in it for them. After all, we have a daily status meeting to review everyone's changes, we print off all our status reports and go over them on by one. What could be simpler?

I'm not sure how to explain the value proposition of a wiki to folks who think that a daily status meeting is the most effective way to keep everyone informed.

Sunday, January 27, 2008

Proper Web Design

I was shopping power tools at my favorite source of tools (sears.com of course) and I again gritted my teeth at the apparent lack of concern about web design. I'm still amazed that, in the day of widescreen 22" monitors, people still design web pages like it's a print ad. Listen folks, the web is NOT a glossy print ad to be included in the newspaper. It is a platform that can support many layouts and screen formats.

If you don't understand, but are trying to market things on the web or design a web interface, please read the following:

Craptastic examples include most, if not all the big-box retailers:

Nicely done stretchy design is: