Russell and Associates - Forum

I was recently employed by a very small company as a consultant through a regional tech employment agency.  It was my first experience working for a small company with fewer than 2000 employees – this company had less than 12.

During the interview, I noticed there was the personable and relaxed atmosphere.  The company was comprised of individuals who had worked together for 12+ years.  Even so, as an outsider, I felt very welcomed.

Being used to more formal environments, this was going to be a welcome change; at this small company, there appeared to be a very hands-off management style.

After doing my very best to acclimate myself to the new code environment – a proprietary framework written in Java/J2EE within - using Eclipse (Helios) , I got down to work creating JSP pages, integrating jQuery (jQuery core and jQuery UI, and plugins – validate, default-value, alphanumeric, extjsoncookie, simplemodal).  The documentation for the custom framework as well as the assigned project was very scarce, consisting of a few use-case documents (no diagrams, just words).  The data schema was ‘evolving’ during the project, and, the data definitions and relationships were verbally defined – difficult to reference

All in all, not enough documentation to get down and dirty with a project that had a very fast timeline.  There were 3 complete site redesigns (aka major changes)  in 4 weeks – just when you get progress, you have to start from the beginning.

What I learned from this experience is:

• Clear, concise, and complete documentation is VERY important – not just words, but diagrams (use-case, process, flow, data, etc) – for any web application.  Smaller companies may not necessarily have the resources to accomplish this in a meaningful way, so be sure to set time aside upfront to create the essential docs to keep your team productive.
• A large enough team to bounce ideas off of is a tremendous asset – 3 or more developers working together with different skill sets is, in my experience, a minimum number - when there is a tight timeline.  That provides you with the necessary division of labor – MVC.  If time is not a primary factor, then a team of one front and one back-end developer would suffice.
• Having the developers intimately involved with the evolving design (database, page flow, SEO, UI, etc) benefits the company greatly.  There is an internalization and participation with the requirements that adds value during the code creation process – the more you know, the more you can do.
• Timing is critical - having the third-party designs ready BEFORE a developer gets on site, a development path defined, class and data definitions documented (particularly with a custom framework), and a team of resources that are available at a moments notice for any roadblocks that arise.

The working environment and culture at the small company was far superior to that of a large corporation for my personality and work style.  I was lucky in two more ways – the company president was exceptionally competent and creative (with a tech background), and the lead Java framework developer was a very gifted programmer.

When approached to take on a project with a speedy timeline, it behooves the consultant to weight the pros and cons of working with any business entity.  Before agreeing to consult:

• review the available documentation for the project -
  • are they concise, appropriate, and cover the breadth of the project?
• get a list of assets you will have ready access to during the various phases of the project life-cycle.
  • who will you be able to contact for business/marketing and technical issues outside of your area of expertise?
    • Business analysts, project managers, content experts, etc.
• make sure that the budget is realistic and you will not push the project over that thin, and sometimes arbitrary, profit-margin.
  • You don’t want to get on a sinking ship – if the budget is not realistic, let the company know.
• is the time-line reasonable/attainable given the above information?
  • If you see a lack of  any of the above attributes, you may be wise to walk away IF the company is not receptive to scaling back, adding assets, or proactively creating the necessary documentation.  If they want to understand and are willing to alter core aspects of the project, you may be joining a winning team that extends beyond this project.

When analyzing most things in my life, I use the simplistic who, what, when, where, how, why matrix.  That, I will define in a later blog – if it even needs defining

Thank you for reading – Vic.