A new episode of Drunk on Software is online.  We talk with Bruce Eckel in this episode. Let us know what you think!

In the latest installment of Drunk On Software, we dicuss Anvil with project founder Ryan Knight.  Ryan is a colleague of mine at Gorilla Logic. Enjoy the video and let us know if you need any more information on Anvil.

I am guessing I read this somewhere at some point, but my current project has motivated me to think about tight coupling and its impact on productivity.

I am a big believer in the idea of “flow,” where developers find their rhythm and begin to move through things quickly.  Over 10 years in the software development industry, I have encountered two times where the projects I was on never reached a state of “flow” in any way.  Usually, no matter what the challenges, I find the team and myself reach this in some form.  So, it is actually kind of scary to be on a project where we haven’t found this state at all.

The first time I experienced this it was because the needs of an internal customer were so ambiguous and bogged down in politics.  So, we were never able to get a clear picture of what we were to build.  This instance ended with our entire team being laid off as part of large reduction in the work force through out the company.

In the current case, the requirements are quite straightforward and clear.  There is plenty of weirdness in them, but the fundamental function of the system is fairly simple.  From a functionality standpoint, it is probably the simplest system I have ever worked on, outside of dinky web site contact forms and the like.  So, what’s the hang up to finding the “flow?”

I believe it is the high coupling through out the system.  We are working with an internal development team, and our customer has mandated a fully data driven approach and implementation that does little to separate the meta-data from the data.  In most cases, the database tables are being propagated up to the presentation layer, which has created heavy dependencies throughout the system between all tiers of the system.

In many ways, I have always thought the industry was a bit to extreme with the desire to decouple every single little thing, and found many of the driving forces for doing the decoupling to be a bit silly.  However, I am seeing now how much total coupling limits team productivity.  It brings team productivity down to the level of the least talented- least motivated developer, as everyone is always waiting on everyone else.

I think there is a very natural level of decoupling in systems.  We don’t need to go crazy on this issue, but when the natural needs for decoupling are ignored there are many side effects, including killing the team productivity.

At QCon San Francisco 2008, I went to a session with Eric Evans about working in the Core Domain.  It was one of the best software talks I have ever heard, and I am looking forward to InfoQ posting the video so I can share it with a number of friends in the industry.

He basically said to be sure and contribute where it matters, don’t spend your career cleaning up after hackers, allow consequences to happen, the core domain is where the value is, and rewriting legacy systems is generally not a good thing (unless they are just too expensive to operate).

Another interesting thing he pointed out is that his writing on ubiquitous language is about a team, not about an entire organization.  He stated that single monolithic models do not work and differences are ok.  Groups just have to agree on how to translate things that are shared…

The most interesting point to me is the idea of allowing consequences to happen.  I find that most software developers are passionate (including myself).  It is hard for us to allow bad things to happen when we can see them coming a long way off, but I think Mr. Evans’ advice is dead on here.  We have to do our best to make recommendations in hopes that our organizations will avoid costly mistakes, but as my boss tells me often ‘we cannot save them from themselves.’

So, here is to focusing on the core domain, and making ourselves as valuable as possible…

In 2008, Flex reached the tipping point where it went from a technology with possibilities, to wide spread usage.  The year started with Adobe releasing Flex 3 and AIR 1.0 and finished with an updated release of AIR (1.5).  According to friends at Adobe, in mid-2008 there were about 150,000 Flex developers – a number that pushes it beyond interesting, to a viable and growing community.  Also, there were the Sun Deflextions…

In my consulting travels, it went from a technology few knew of in 2007, to one where most developers had some impression of it, or had even done some work with it in 2008.  It has been exciting to see a technology go from the fringes to the prime time.  I do hope that Adobe finds a true revenue model, and Flex doesn’t just become another Java as far as the vendor is concerned.

Personally, this really means new challenges for 2009, as I am tasked with writing RIA content for InfoQ.com and building real applications with Flex.  In late 2007 and early 2008, there was a constant stream of announcements and excitement around the platform.  As 2009 starts, I think it has already become more about the reality of building real world applications.  So, on the InfoQ side, I think my new challenge is going to be providing resources on how to best implement applications on the platform and talking more about the weaknesses of Flex and how to address them.  I guess that is the reality for any platform that becomes mainstream.

All that said, 2008 was an exciting time to be associated with Adobe Flex!

James and I have posted our latest Drunk On Software video, Flex for Managers and Architects.  It is actually the first video we recorded for the series.  Check it out…