Also, my old domain, ectropic.com, still works along with the old feeds.

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.

Anyhow, I couldn’t be more impressed with Apple.  I put in a support request online and was called with in seconds of hitting the submit button.  I was unable to resolve it on the phone, but was able to schedule and appointment for 2 hours later at the Cherry Creek Mac store.  Luckily for me, Stu has recently had a hard drive die on him.  So, I had purchased my Time Capsule and been regularly backing up to it.  They quickly determined that the drive was dead and put in a new one.  After only a few hours at home, I was able to restore from the Time Capsule and I am back up and running with all of my files intact…. After years of owning PC’s, I couldn’t be more impressed.

Even better, was seeing Peter Forsberg in the Mac store while I was waiting.  I cannot imagine losing a hard driving ending up better…………

Ignoring those types of issues, judging code is difficult because we do not understand the reality of when the code was written.  Was the code written with an extreme deadline?  Was it built with a clear expectation of being prototype code and then put into production by some aggressive manager?  Was the architecture changed multiple times without time to rewrite / refactor?

In addition to not understanding the actual circumstances around the time of original development, developing perfect code is expensive and there is a point where we all need to ship our imperfect code and move on.  Only a really rich, somewhat misguided, client would pay for the real amount of time to develop perfect code.  And of course, we have to understand that much of our feelings toward code come back to style and preference, and not everyone has the same approach to these items.

So, let’s all try and buck the tradition of bashing the last guy’s code, and when there are real issues that need to be addressed then please approach them gracefully.  Remember, someone will be following you soon too!

In the first episode, we talk about the Adobe Flash Player 10.  James shares about the main updates of interest to developers.

Please contact us if you are in the Denver area and would like to appear on the Videocast.  We would love to have you!

FlexBuilder provides a high quality IDE for developing Flex applications, especially for Java developers already familiar with the Eclipse IDE. It does cost money – please get over it. Good tools do tend to cost money, even though the Java community seems to have thrown this notion out the window – partly because we have adapted to using inferior tools.

I will say that it is a bit of a stretch for Adobe to suggest that the Flex Builder is ready for enterprise development on Linux. I have been living the Linux Flex Builder there, and there is absolutely no refactoring support (painful). This is an essential feature for any modern IDE. I know they have released the Linux version under Alpha, but many of their people have proclaimed it as bringing Flex development to Linux. There doesn’t appear to be any roadmap for when one can expect these features. So, I wouldn’t expect them anytime soon – my personal solution was to buy a Mac. Also, this is completely independent of the runtime – the Flash Player on Linux seems to work quite flawlessly in my experience.

I have finally gotten the chance to immerse myself in Flex code lately. I decided to do this series to capture my first hand experiences with Flex. Please share your feedback on the challenges and strengths I highlight. I would love to know if your experiences differ, or if you can fill in some of the gaps where I might be missing something. For those of you considering Adobe Flex, hopefully this will give you an accurate picture of building applications with Flex.

We have spent a bit of time evaluating FlexUnit and DPUnit. Both seem decent for unit testing, but don’t seem to solve the problem of doing full on automated UI testing for Flex applications. We are looking at a couple of recording tools (HP QuickTest professional & one from IBM), but it appears that they will be in the 5-10K range (and we can’t seem to get a call back from sales as of yet…). We really need something like HtmlUnit for use with traditional browser technologies. HtmlUnit allows us to mimic a client browser programmatically, and validate that the actual user interface renders and accepts input correctly. Is this what FlexUnit and/or DPUnit are supposed to do for us – are we missing something? If not, how are you approaching the testing of your Flex applications?

Click here to subscribe to my RSS feed and follow the rest of this series along.

The true object oriented nature of the Flex components is excellent. I am sure there have been a number of “real” UI frameworks over the years that did things like this, but I have never had the opportunity to work with one…. So, being able to actually apply OO principles to UI development has been a pure joy. In addition, the Flex framework provides virtually every component I could ever imagine being needed for enterprise applications. This was always a huge challenge with Java web frameworks, as they always seemed to depend on the community to fill the “gaps,” if you can call the components of UI framework, the “gaps.” Anyhow, there are a few issues that seem to come out of the maturity questions I raised initially. For a few examples:

1. The default button implementation does not offer the ability to wrap the text. The fact that the components are really OO paid off here, as we were able to extend the core button and add this functionality. It was nice to be able to be able to work around the limitation this way, but this is clearly a common thing that people would want to do with a button.
2. We have been experiencing general difficulty with the ComboBox. It was surprising to have to set things manually – not being able to provide a reference that has the same value, but having to find the actual object in the list and provide him for setting the selected object, etc… The data grid layout breaks out of the columns on us when our custom ComboBox is clicked on… just weirdness.
3. Another surprise was that there was no default option to allow users to resize the default components. This would seem quite natural for an animation engine. Anyhow, we used the following to implement resize on our custom title window pop-ups: http://myflex.wordpress.com/2008/03/05/resizable-collapsable-titlewindow/. We made a few tweaks for our custom needs, and did our best to hide this in our implementation so we can easily replace it if we find a better implementation.

Also, here a quick link on styling – since it took me a while to find this: http://examples.adobe.com/flex3/consulting/styleexplorer/Flex3StyleExplorer.html.

Click here to subscribe to my RSS feed and follow the rest of this series along.

Overall, the Flex programming model is enjoyable and easy to use – minus a few annoyances with ActionScript, it is a pretty elegant language (I would like to see abstracts and private/protected constructors added). Having the MXML declarative abstraction on top of AS3 proves to be quite genius. It makes laying out graphic components quite easy by hand, and would seem to be what really empowers the visual editor.

For a Java developer, ActionScript brings my first hands on experience with closures. I am no language expert, but what is all the debate about? Of course closures should be added to Java. I know there is quite a bit of nuance on what the syntax/implementation looks like, but it seems pretty obvious that this functionality can greatly reduce the code to implement any number of things.

I am finally learning to take advantage of the event model in Flex. It took me a while to train my brain to think in terms of events and listeners. I am used to taking a much longer path to wire things together. Not to get too far off the tracks, but with this in mind I am surprised that anyone would want to use a heavy weight MVC framework within Flex (especially one that looks more like MVC2). The separation of concerns seems quite natural in Flex. I am not a hater of MVC frameworks – I have spent my fair share of time in Java MVC frameworks, but they seemed much more necessary in a Java web world where all the core language provided was JSP pages.

Click here to subscribe to my RSS feed and follow the rest of this series along.