Tuesday, October 11, 2005

Framework Translation/Conversion

Now as I get closer to when I take this Fusebox class, and I keep hearing really interesting and different posts on frameworks, methodologies, I am kind of seeing a change what my real concerns with different coding methodologies instead of just my core emotions...

Really the problem was that we all code from different situations. Some of us code solo, some of us do agile partner coding, some of us do team coding, we all do it in different ways.

So then the bigger concern is how can the different situations work together well...

I think there should be a form of etiquette to help us work together better...

For example if your a web shoppe, your coding methodology should adapt itself to whatever coding methodology the client's code is in. Unless your the only people doing codework for them.

However most of the time, fore big companies, lots of different web shops have done code for them. So to all have different applications, created completely differently makes sense.

Sure you can introduce new methodologies or frameworks to your client but if they're not signed off on the latest method/framework then stick to their style.

We all like to code in different ways, or experiment but why are we experimenting with them at our clients expense?

Above are experiences I have seen at different client companies I have worked at. Where the outsourced code would be done in fusebox or cfc's and 99% of our code was still standard CFML.

Either then all code should be converted to X framework/metholodogy.

For example, at one company our checkout ecommerce code was outsourced to a web shop, and the result was a CFC and application that interfaced with that CFC. I am sure it was very interesting, but none of the rest of our site's code was in a CFC, and are CFC's always the best way to go?

We really need a multi-part solution:

1. What framework/metholodogy consisteny should we use for our clients? Do we use our favorites or use the clients? What if the people that work at the clients dislike your methodology?
2. When is a good time to introduce methodologies to clients? And when is it not a good tme?
3. Which kind of frameworks are best for which kind of applications? Surely there is a performance guideline both in terms of ease of setup, scalability, modularity, there has to be a measuring stick so we know which tool for which problem.

Because acting in the dark like we are isn't very healthy.

I want honest conversation, honest questions, I am here to help us be a better industry. If you just want to flame, please go elsewhere...


  1. I'm a client developer which, for Flex and Flash, currently doesn't have a lot of options.

    To me, the way code works is based on those who code it, and what situation they are in. Therefore, the way it's made (CFML/CFC/Hybrid/Framework) is based on:
    - developer's style
    - developer's competence level
    - developer's experience level
    - version of software
    - deadline
    - scope

    Assuming deadline is inversely proportional to pressure which adverserly affects quality of code, then all 6 factors can greately affect how the code is written.

    ...however, everyone knows how "Fusebox" works, or any framework for that matter. If you are not familiar with Fusebox, once you are, suddenly you will imedeiately have a good understanding of other Fusebox frameworks.

    Yes, it helps to have a good understanding of what the app actually does, but having just those 2 things precludes you from not having to know the 6 attributes above. Although some will be immediately apparent, you don't really need 'em. You know what the app does, and from your knowledge of how Fusebox works, you can navigate and start to glean how the code works as well... VERY quickly.

    Methodologies are one thing; people choose to follow them or they do not.

    However, a framework is a set of rules that not only define how you work, but what you work with.

    MVC, for example, a design pattern of Model View Controller, or data, gui, code to glue to the 2 together. If an app is written using that, you know to look for those 3 places... vs. starting at ground 0 and going wtf. OR, if someone says it is MVC, and you don't see those 3 basic elements, then you can assume the first 3 attributes of the list above are f00ked, and your in for a rough ride.

    ...this also assumes a framework is followed correctly, or that a framework itself is insulated enough from scope creep.

    Bottom line, frameworks have helped me do the following:
    - know how to shield myself from scope creep; my app is more manageable
    - simplify the notoriously large controller code; my data goes into my view, my view changes my data, tra-la-la-frikin-la
    - if services change, I only have to change 1 line of code
    - data is accessible freely and easily for those who need to know about it
    - multi-step processes are made tons easier
    - debugging is expediated and requires less beer afterwards to dull the pain
    - most importantly, if someone else used a framework I know, I immediately have a general idea how the app was built

    ...as far as your other questions, I'd say they are more a result of the state of the industry and technology. I don't know CF, so I'll pick on Flash.

    Qualified Flash Developers, not designers, are hard to find. Additionally, defining what "qualified" means is tough. The industry is already thrown another curve ball now that Flex will become affordable.

    So, many of Flash & Flex clients get expensed the learning curve, and the growing pains of an old technology thrown into new markets that we don't know how they fit yet.

    If everyone knew MVC, ARP, and it was determined that was the best way to develop Flash applications, then I wouldn't be making this reply.

    Everyone is different, so they code differently; there are no enforced rules in code saying you must code some certain way.

    Everyone has different skillsets, so some just don't know any better yet. We all gotta start somewhere.

    Some are smart, but aren't experienced, and havent' done things the wrong way yet. Some have been told, but would rather learn the hard way.

    Some are using older versions of software because they cannot see the business case for newer ways of doing things where their existing ones meet their needs.

    Some deadlines make most of the above idealistic bs go out the window.

    Some projects are larger, and require different approaches both short and long term.

    I hope I was somewhat on target to your post.

  2. A very nicely written comment, and yes. My goal is to find ways to work together, not start another flame war.

    Thank you!

  3. who says anybody's "acting in the dark"? can you expand on what you mean by that?

    as far as using certain framework "consistently", people who are well versed in multiple frameworks (FB, Mach-ii, model-glue, etc) will tell you that even with that arsenal of tools, there's a proper tool that's appropriate for a given situation. fusebox might be better suited for a given application than mach-ii. model-glue might be better for a given application than fusebox.

    as far as wanting to code in a particular framework for a given client, but the employees at that client don't know the given framework, there are 3 choices, all of which are perfectly valid. 1) you don't take the job. 2) you take the job, but don't apply the framework (just because you know a framework (or frameworks) doesn't mean you no longer remember "plain old" CFML). 3) you plead your case for using the framework to the client and the client agrees that it's the best way to go.

    Now, to be very honest with you, I'm in much the same place that you are. I'm just now starting to try and get into various frameworks. After a few false starts, I'm probably going to shoot for fusebox, as it seems the easiest for a ColdFusion developer (and not someone who is well versed on OO concepts).

    But where you and I seem to differ is that you don't yet seem convinced that frameworks are good. Or that there should be only one 'standard' framework.

    I think the more you read, the more you learn, your mind will change on those points. I think you'll start to see that different frameworks have different strengths/weaknesses and there is no single one that is always the best for every situation.

    You said you were going to the class being held by Jared? If so, I think that's great. My recommendation to you (for whatever it's worth) would be to try not to convince yourself of anything (one way or the other) until at least after the class.

    All of the questions you present in this post? Forget about 'em. Think about anything else you possibly can up until the class. Then take the class with an open mind. After the class is over, I wouldn't be surprised if 90% of your questions have answered themselves.

    Afterwards, -if- you have more lingering questions/doubts...ask away. But I think you'd be doing so from a more informed perspective which might make it easier to understand the answers ..and just to be perfectly clear, that's not a slam...i'm afraid that as easy as it is to misinterpret the typed word, it could be construed as such. please don't take it that way.

    hope that all made sense. it's late and i just got home from a painfully long day at work :)