Tag Archives: development

Disease:

“Programming In Spite Of Flex Framework syndrome” – A.k.a “PISOFF”, pronounced “pissoff”: A serious project-life-threatening disease that often goes undetected until it is too late. Occurs most frequently in the first few projects of a novice Flex developer, however rare cases can occur in intermediate to advanced Flex developers. In almost all cases, victims are intelligent, experienced programmers who are transitioning to Flex from other development environments that they have been proficient in.

Symptoms:

  1. Code bloat
  2. “Freaky” problems (i.e. UI flickers / inconsistencies)
  3. Maintainability / transference problems
  4. Inconsistent methodology
  5. Inconsistent user interface standards
  6. Lack of encapsulation / code reuse
  7. Increased development time
  8. The feeling of “this has got to be easier”
     
Causes:
  1. Lack of knowledge and practiced skill of using and properly appropriating the tools available in a given framework.
  2. The attitude that the learning curve vs. benefit of learning and appropriating the components of the Flex framework is too steep and the benefit too little.
  3. Not enough time to learn the framework, but up against a deadline to produce a project in the framework.
  4. Typically intelligent, experienced programmers will tend to draw similes like “oh X in Flex is just like Y in _____” and miss out on paradigms that are introduced in Flex that may not have a direct correlation in another language or appropriate best practices in another language that aren’t necessarily best practices in Flex.
     
Remedy:
  1. Place a priority in learning the framework and not just the minimum to draw something on the screen.
  2. Make resources and practice material available.
  3. Be willing to prioritize and accept that code will need to be refactored until you become really skilled in the framework.
     
Rehab:
  1. Unfortunately, existing code will need to be refactored. It’s tempting to say “it just works, so let’s leave it alone”, but not only will refactoring the code ensure that it is executed properly, but it will also provide a learning opportunity.
  2. Timelines on existing and future projects will need to be adjusted to accommodate the required learning.
     
Prevention:
  1. Recognize that with every new framework, the risk of PISOFF exists, and that it can sneak up on you and bite you in the tail if you don’t preempt it, even if you consider yourself an advanced developer.
  2. Don’t undervalue small exercise projects that exist only to learn what the framework provides.
  3. Educate all developers about the risks, causes, and prevention of PISOFF.
     
I don’t want to be silly in presenting this as a disease. We need to label it and treat it like one; or, just like other diseases and disorders, you just brush it under the rug until you find yourself in a pine box. It’s not convenient, and it may not be immediately apparent if you aren’t aware of its existence, but it’s real and it’s deadly, and your project might have it.

We’ve been using this for a while now, and I’d just like to tell the internets that Charles is awesome. I would definitely recommend it.