Ext4 Impressions

I have been using Ext for years, starting with 2.0.  In most cases this is paired with Ruby on Rails on the server and has generally been nice.  There were some growing pains in understanding that Ext is not like jQuery.  It isn't meant to enhance the page it is meant to control it.  Once it is understood that ExtJS is an event driven UI layer much like MFC (Microsoft) then things are rather easy to grasp.

In fact, Ext (pre 4) is almost just like MFC in that it is primarily a collection of UI widgets that you can put together in any way you wish.  This is great for very small UIs that do not have a lot of interconnected parts, but once the number of interconnected item reaches more then a few (say 5 or 6) then it is nearly impossible to map all the emergent properties mentally.  Enter MVC.

MVC is a design patter created over 30 years ago, whose sole purpose is the separation of concerns.  Business logic (model) is separated from UI (view) and they communicate via a defined set of actions (controller).  Anyone familiar with UI programming should be familiar with this pattern.  It is used in almost all major UI libraries except ExtJS, until now.

Ext4 aims to fix this flaw by retooling the framework to be MVC.  It is almost successful.  There is a major problem in separating models from collections (which is understandable given Javascript's nature) but there are more elegant solutions then the one Ext4 uses (see SproutCore and Backbone).  There are far too many annoyances at the model level for me to detail here, but as an example the LocalStore and MemoryStore are broken as of this writing and cannot update or remove models since they do not fire events.  This problem can be seen is a number of their own grid demos.

I also tried to use the compatibility mode to convert an older Ext3 app to Ext4.  I was successful in removing all of the errors and most of the warning, but could not get the page to render.  Each component thought it was rendered, but no DOM was presented to the browser.  Lots of digging later and it turns out you can't mix MVC Ext4 objects with non-MVC Ext3 like objects.  Not sure why, and without errors it is hard to tell what went wrong.

Finally I started from scratch and created extjs4-frame so that I could dig in without having to worry about Ext3 compatibility screwing things up.  Thing did not go much better.  I watched the videos and then dove right in.  As expected what was shown on the videos (obviously dumbed down) worked as expected, but as I started to add complexity things would break in mysterious ways.  Turning to the documentation was only marginally helpful, since it appears that it has not been full updated.  Also, some of the documentation does not match the JDoc comments in the source (probably human error in generating the docs).  This is an annoyance to be sure, but not a show stopper since I know how to read Javascript (as anyone that would be using ExtJS should).  However, documentation error (especially when generated from embedded comments) are indicative of a lack of attention to detail and since they do not provide their unit tests I can only guess that their storage engines are not well tested either.

Pros

• Documentation videos are a nice touch
• Simplified code due to the MVC nature
• Sensible file structure (forced)
• Auto-loader (turn off in production, but great for development)
• Better stack and error handling (as compared with Ext 2/3)
• Trees use real models (meaning the server can respond with any hierarchical objects)
• Non-flash based charts
• Smaller size (as compared to Ext 2/3)

Cons

• Difficult to understand (even for those with MVC and ExtJS experience)
• No backwards compatibility (the compatibility mode is a joke)
• 4.0.X versions are not guaranteed compatible (there are still a lot of internal changes going on)
• Documentation does not always match source comments and is not always correct (save some time and just start with the code)
• Inconsistant Model/Container behavior
• No generator scripts provided for aiding design patterns
• No unit testing framework provided
• No JS compiler/minifier provided (one that can read the requires directive is almost a must now that they exist)

Overall

Wait for 4.1 to see if things stabilize.  Or switch to SproutCore.

Problems with Agile Implementation

I really like agile programming.  It keeps me close to the action, and makes me have to think about my next moves.  It also keeps me informed as to what is going on around me.  But in my many years of using agile I realize that, though the process itself is very nice, its implementations can tend not to be.

Problem don't arise from agile itself, but who and how it was implemented.  If the implementer's goals do not match the Agile Manifesto there is little chance of success.  I have used scrum many times and the most common problems I see are:

1. Agile as Micromanagement
2. Agile as a Whip
3. Agile as an Excuse

Agile as Micromanagement

It looks like:

1. Having to break task down into hourly segments of work
2. Having to break task that logically have to be done by a single person
3. Having to account for ALL time taken, even time not related to code like attending meetings

Agile tenet misused:

1. Individuals and interactions over process and tools
2. Working software over comprehensive documentation

This happens when a manager (chicken role) is the Scrum Master or when the Product Owner has say over implementation specifics.  It is a confusion of roles, which in turn leads to a confusion of goals, which in turn leads to over documentation.

Agile as a Whip

It looks like:

1. Filtering a burn-down on an individual basis
2. Placing more in the sprint then can be done (but still requiring it all to be done)
3. Associating points with people (publicly)
4. Associating number of tasks done with effort
5. Associating points with hours
6. Basically anything where measured output is more important then people

Agile tenet misused:

1. Individuals and interactions over process and tools

Anytime you associate numbers with people you have created a crab mentality.  Their focus will stop being on software, but on making their numbers better.  Those that are better at number games will succeed, those that are better at software will fail.

Anytime you put your people under undo pressure then simple mistakes are made.  This is going to later erode confidence in the team.  It is going to happen like this: "you missed a comma in a Javascript file which causes it not to work in IE.  That was such a simple mistake to have tested for that I am not sure you are testing any of your code."  The problem was caused by 4 hours of sleep in 72 hours of coding at the end of an over-extended sprint.  The programmer was nearly delirious.  It is shocking it was the only mistake, not that it was a simple mistake!

Unfortunately I have seen this situation start innocent enough, with comments like "we don't want to over work the staff" or "we want to make sure they always have something to do" or "we want them working on the correct things".  If the "we" in question is management (chicken role) then there is probably already micromanagement going on, and Agile is being used as whip to solve the problems created by the bad implementation.

Agile as an Excuse.

It looks like:

1. "You said it would take XXX.  It took YYY.  You need to make up the difference out of your own time"
2. "We cannot slip these date, and you have already pared back the release N sprints ago.  You need to put in extra effort"
3. "Agile is about being agile.  Even though we are mid sprint we are radically changing direction, but we are not canceling the sprint or doing sprint planning.  We are just swapping out some tasks for others."
4. "You picked the language.  It is now your problem to bring this project to conclusion and under budget."

Agile tenet misused:

1. Individuals and interactions over process and tools
2. Responding to change over following a plan

These are all excuses I have heard.  Each time given by a person in chicken role (managers) because they are ignoring changes in the field (military term).  Every choice has a set of outcomes: some good, some bad.  The attempt with agile is not to mitigate bad outcomes, but to allow those outcomes to contribute to the overall direction.

Sometimes the bad outcome will be that something took to long, or that one language/tool was not the correct choice given the problem set.  If for every problem that happens the developer has to take their own time, or face embarrassment, to solve the problem then they will stop making choices.  Not just choices that might have bad outcomes, but choices altogether.  At which point someone in a chicken role will start making more choices then they should.