Monday, February 20, 2006

Flex - A Call to Arms

Inertia is a terrible thing in developers. There is nothing more depressing to me than walking into a cf shop and finding that they are still using CFStudio 5 with a single development server supporting the entire department. I usually find that this is an outfit that was unable to keep their visionary developers and now have a room full of grey cube drones, pounding away at uninspired code. No one in the department has ever been to Max or CFUnited, no one actually knows where the closest cfug is, few have actually read a blog, and no one actually has a copy of flash.

There is a lot of blame to go around when you find an organization like this. Part of the blame goes to the individual developers. They have been complacent enough to allow their curiosity and hunger for knowledge be driven out of them by the organization. Most of the time, the truly inspired have been frustrated to the point of finding a different position. Or worse; looked down upon by the organization as trouble-makers and malcontents.

A larger part of the blame goes to the lead developers and project managers. They are the ones that let their day-to-day responsibilities crowd out a spirit of innovation and discovery from their teams and departments. While the developers are responsible for the stagnation of themselves, these people are responsible for sucking the life out of groups of 5 or 10 people.

The largest part of the blame has to go to executive management for being out of touch with their core business processes. They are the ones that have failed to realize that by not exploring new technologies, they are ceding competitive advantage to the competition. They are the ones that have failed to recognize that changes in their companies initiatives have gone from sweeping technological breakthroughs to functional tweaks.

So, if you have suffered through this post to this point being insulted along the way, here is your official kick up the arse:

Official Kick Up The Arse
Developers: Download the Flex Beta now. Do it both at home and at work. If you are working in ColdFusion in any capacity today, you will be affected by Flex in some way. Get to know it now so it doesn't trample you when it's forced upon you. Exploring it is great fun. It brings back that "lightbulb" effect when you first get something to work the way it should. You will start to see where your upcoming projects could be made more engaging for the user and more fun to build for you.

While your at it, try downloading cfeclipse. Once you get it configured to the point where you can actually work on a file, uninstall CFStudio 5. If you are still using CFStudio5 a month from now, expect another big kick up the arse. The rest of us will all be pointing at you and laughing.

Project leads/managers: Take a risk. Set aside some time for your developers to look at Flex. Let them come up with a small project that they could build that could be used internally. Something that won't break the bank but that could be made visible to other parts of your organization once it's in place. You know there is always a list of small products your toolsmith wants built that never get paid any attention. Maybe there is something there you could put together.

Your developers will find lots of other uses for the technology as they build. KEEP A LIST! Take credit for spearheading the research activities.

CxOs: If it is important enough for your company to have a development team, then you realize how important it is to use it to make your company more competitive. If your teams spend 100% of their time working on maintenance projects or incremental improvements in existing software, then either 1) your development team is too small, 2) your middle management lacks vision, 3) you're milking your Cash Cows (hey, that's funny), but not building Stars in your quest for short term gains.

It's time to kick your teams out of their rut. Spearhead a labs group. Make sure it has access to domain specialists across the organization. Devote at least an hour a month to stay in touch with the group. Make sure that the person you choose to lead your labs group reports directly to you regarding this part of their job. Provide the Labs manager with the authority to draw resources from the rest of your organization within reason. No one should spend more than 20% of their time on labs projects until you find a project that you decide should move into development.

Ok, that's it for this kick up the arse. Feel free to post here if you want another ;).


  1. OH Hell Yes, Brother! AMEN. I say it again - A-MEN!

    BTW, Are "Custom Tags" useful? We haven't started to explore them just yet. ;-)

  2. Eww, Custom Tags.. I've seen so much CF 5 Custom tag trash in the exact environments which Mike is describing. I use them to format queries in display pages and the like much like JSP tags, but that's about it.

    The CFMX platform has been out for several years now-- if you haven't at least learned the basics about OO and CFC's yet, ouch!

  3. Sorry for the anonymous post, but I'm currently consulting for a Fortune 500 company with over 30,000 employees, trying to convince them that source control is a good thing. Argh!

  4. What's wrong with custom tags? They can be misused just like any part of CF. They may not be as sexy as CFCs, but they are still quite useful, just are plain ole UDFs outside of CFCs.

    -Raymond Camden

  5. Ray-- yep, you're hitting the spot which I probably didn't address well with a quick comment; they are good for simple tasks, but when writing something more complicated than a simple UDF type task, to me it makes much more sense to go to CFC's. Usually I just stick most stuff like that within CFC's anyway to keep all of the model type code in the model.

    For instance... writing a full shopping cart application which you only call via a single custom tag easily ends-up being a big ball of spaghetti code which takes forever to debug, etc. And admittedly I've wrote some code like this for a banner ad system at a previous employer (pre-dating CFMX) that is still actually in production on around 100-200 websites, so I don't think I'm terribly biased about it since I've done both. :)

    Back in the day they were the best way to go if you wanted something modular that you could move from site to site, etc, but now it seems like a much better idea to encapsulate most things within CFC's if they belong in the model of a given application rather than having a bunch of random custom tags to keep track of, but it's just my personal opnion of course.

  6. I'm not so sure in all cases having a single development server is a bad thing. I work in a company that drives it's template logic out of a database. The database is 15Gb of articles, customer and general data.

    The application has a fusebox like xml config tool that is built in the database and send out on requests. So in essense we couldn't run separate dev environments unless we had 11 15Gb databases around the place which is unworkable.

    We still manage to do good source control and have tight integration using XP practices.

  7. In general, I have yet to see a strong argument for working off of a single development server for a team of developers. From the comment from anonymous, I'm guessing that he is working with 10 other developers. When someone on that team is working with a part of the application like a user login or a part of the application's architecture, any coding error reduces the entire team to waiting until it's fixed. Not very good for productivity.

    I'd be interested to hear how source control in this environment is set up. Are there 11 copies of the software running in individual workspaces on the dev server? If everybody is sharing a single working folder, what happens to everybody's work when someone on the team wants to refresh the project from the source control database?

    As far as the db goes, it's normally not necessary to replicate the db. Just set up the datasource in your local copy of cf. In cases where you have to do some radical work on the db, a copy of the db schema and a sample of test data usually works well.

    Working locally has lots of benefits:

    ~ You can work on your application in a disrupted state and not bring down the entire development team.

    ~ Your team gets the opportunity to work with and learn about installing, configuring and maintaining both ColdFusion and a web server.

    ~ Your applications get replicated across an entire department of PCs which helps protect against catastrophic data losses (dev server also houses source control and the drive croaks).

    While my experience is anecdotal, I constantl find this type of setup in older fusebox shops. The only reason I can think of for this is that the applications in these shops pre-dated the developer edition of CF. I can certainly understand working on a single server if you had to buy a license for each developer, but those days are long gone. In a positive light, it's also a testament to the staying power of fusebox apps.

  8. Hi Mike

    to move away from "single dev server", "custom tag" comments and back to the core issue of your post....

    when I saw Sean Corfields' extract of your post I thought "bewdie: I'll send a link around to all the guys here" - thinking to swell the local CFUG numbers and at least "tune into" FLEX.

    But after reading your origional I dare not! it's far too close to the bone. If I *did* suggest your post to them I'd get lynched!

    the truth hurts.

    Besides, they'd all freely admit that all the points you mention are true and apply to them ... but that doesn't necessarily translate to a call to action. Part of it is inertia, sure but also there are bigger fish to fry: having legacy systems and getting product out the door to name some...

    There *are* a couple of inovators here that do lots of research on new-tech but the trickle-down effect to others seems a bit "thin". It comes down to a "desire".

    and some will *never* change and I should give up thinking otherwise.

    Oh, well.

    I think I'll just stick with trying to make my little world "open minded" and work towards a "center of exellence". At least I care and am willing to get off my backside ...

  9. Hey Barry,

    I feel your pain. I'm convinced that there are lots of organizations just like yours that we never really hear about. The approach you mentioned at the end about maintaining your own little island of quality can work really well sometimes. You just have to show some of the work you're doing to a few sympathetic people in your organization occasionally and do a little bragging. Flex can be made remarkably compelling to people outside IT by just adding a little eye candy and some animated transitions. Throw in a few animated graphs and you can see the jaws dropping occasionally. Unfortunately, it can take a lot of personal time to do it if you have an oppressive or unappreciative management structure above you.

    I hate it when I go someplace and talk to some developers where you can tell that they have just given up ever being able to work on anything fun. Their managers don't give them any time to experiment or they are stuck on a perpetual maintenance project.

    About once a month or so, I'll drag my laptop or a usb drive into the place I'm working and show a couple of friends what I'm working on outside of their projects. It tends to light a fire under some people, but others you really have to grab by the hair and drag them along in order to get them to look at anything other than what they have been working on for the last 10 months.

    I'm sorry to hear about your potential lynching. I never intended to get anybody killed ;). So, the best I can do is hope for your promotion. If you have a team to direct, you might be able to gently "encourage" an exploration of some recent technologies.

    I think that by striving for the ideal solutions, there is every probability that we will improve the situation, even though the ideal can never be achieved. Being content with mediocrity for pragmatic reasons dooms us to never doing anything better than what we have already done.

  10. Agreed to some extend. However, don't discount the notion that progress/advancement/competitiveness/etc exist in areas other than interface (i.e. Flex). There's more to being innovative than building RIAs.

    Don't discount the idea that IDE does not make a bad programmer good, or a good programmer better. It won't keep a terrible programmer from writing terrible code. It won't write a perfect regular expression for me, or help me design the API with which I've been tasked. It helps smart people do the smart things they have to do, and that's it. Laughing at the guy down the hall b/c he's using Studio seems unfair, when the guy up the hall who can't write a 2-D array is using Eclipse. He deserves your attention, not the Studio guy.

    Sometimes, good programmers are busy kicking a lot of ass in other areas and simply don't have time, or interest, in making their googaws glow and collapse and drag and drop. Maybe when they go home, they just want to be with their kids and don't want to sit in front of the computer all night.

    Your point about CxOs, lead developers, etc are all well met. However, don't write off those cube drones sitting beside you. The might be doing the day-to-day drudgery that all organizations require of its programmers, affording you and others the time and luxury of making advancements in other areas.

    And don't write off the guy up the hall designing the database that drives your Flex-driven RIA in the first place.

  11. I'm with Mike: I hate it when I go someplace and talk to some developers where you can tell that they have just given up ever being able to work on anything fun. Their managers don't give them any time to experiment or they are stuck on a perpetual maintenance project.