mike.mainguy

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

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

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: http://www.ibm.com/developerworks/websphere/library/techarticles/0703_wallaker/0703_wallaker.html http://www.kmworld.com/Articles/Editorial/Feature/Beyond-enterprise-portals--40497.aspx This latter link is a better statement of my problem.

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

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.

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

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.