Friday, May 20, 2005

Adapting Your Framework

In the last couple of months, I have been doing a lot of thinking about frameworks. They certainly are very important, and each has it's strengths and weaknesses. But are we choosing our frameworks for the right reasons?

One of my favorite football coaches of all time, Bud Grant, wrote one time of adapting your strategies/tactics to match the strengths/weaknesses of your team. "Make the Playbook Fit the Players".

For example, if you have a lot of great running backs, you don't try to force your team to be a passing team, and vice versa.

Now how does this go towards picking a framework?

Because we can't simply pick one, and assume it will solve all our problems, because there are always changing factors to the team that helps to create/update/fix the applications.

Because a framework has two end-users, the coders who work with it, to hopefully churn out high quality applications, and the end users who use the applications, hoping for high usability, efficiency and scalability.

Each has a different need, so what we really need is an Adaptive Framework/Metholodogy that adapts as both ends change.

What things does an Adaptive Framework need?

1. Easy to read code - Each company should pick it's own style, but document that style.

A. Naming Conventions - for filenames, folders, variables, it has to be well documented and referenced to in each root application. So that 5-10 years from now, someone can come in and reasonably easily read your code.

B. Indenting - Adding to the elements that make code more easy to read. This takes a lot of time, to develop as a skill/discipline, but it pays off, in making the code much more easy to read.

C. Comments - No one is a mind reader, and as applications get more and more complicated, the need comes for more comments not less.

D. Documenting Applications - As your sites/applications get more comprehensive it really becomes important to document every aspect, so in if anything happens to you, someone can easily pick up from where you left.

2. Making applications easier for end users

A. Each application must be a seperate file name, instead of all applications coming to one file name. This makes it easier for bookmarking, and that makes it more likely to be visited again.

B. Search Engine Friendly - Take the long view, and prepare your applications for maximum popularity, meta-tags, description, keywords, page titles.

C. Usability - Making sure the end user can use the application, and that any need for help/guidance is made available.

D. Handling Errors - All applications sometimes have errors, either caused by the application or the user or some other fluke, but by being prepared for this, you present a more professional image to the customer.

3. Improve Ease of Coding in teams/solo - It is obvious now that each company has a different setup for who and how many people do application coding, so we must prepare and adapt our framework to each, so that we make it smooth and comfortable for both.

A. In dealing with teams, it's highly important to divide the work according to each persons's strengths, however that has a couple negative side-effects:

1. People will never learn or get the opportunity to learn/practice in their non-strengths
2. People will not get a whole overview of the applications they work on
3. People will get burned out, only working in their strengths

So we must adapt, and perhaps provide job rotation, different people changing what part of an application they will work on.

B. However working by yourself has it's own strengths/weaknesses. While you do tend to get a stronger understanding of the application as a whole, and do tend to explore all skill ranges, your doing it alone, and may not learn new ways of coding, and you may not get better without others to learn from, share and compete with.

C. Companies can no longer afford not to have a training plan, this can be cheap to expensive, but this industry needs to adapt to the technology, and instead of constantly hiring different people for different technologies, it's cheaper and gets better employer longevity by having a training plan.

Simply since most of us in our field are self-taught, as I am, training was never really available, in an official outlet.

So a training plan can be having 1 lunch a week, where a different coder/developer shares a technique; rotate sending developers to different conventions to pick up and enhance skill sets; sign up for local classes; encourage study groups for certification testing.

You hired a coder to do a job, but that job cosntantly changes, you already paid an investment into that employee, why waste that money by not providing training to make them more valuable to you. Most people I know would love to be trained rather than get some kind of IPO or other benefit like in the 1990's.

D. Project Management - This is a must, you must prevent wasting time and money on projects that are not clearly requested/planned. We've all been burned, so plan out every step of the project ahead of time, in written/typed however you like it.

E. Planning applications for scalability in the long term - How many of us want to keep re-writing the same application over and over? Not me. I'd rather get it right the first time. And this involves knowing when to use the right coding method for the application.

Well this is enough of a good starting point, so let me know what you think.

Thank you.

No comments:

Post a Comment