Pencils Down

The Massachusetts appliance rebate program went into affect last week. The state gave away over 6 million dollars in a few minutes. Consumers had to register at a government run web site for a coupon and later go to a store to use their coupon. The site crashed within minutes of opening. Call center volumes were in the many thousands.

A local radio station, WAAF, with a particularly Republican bent went on air lambasting the whole process. Included in the rambling was mention that:

• The government employees involved should have been able to better guage the resp0nse.
• The web programmer(s) involved will probably not be held accountable
• They developed a back-door website which could be used during failover, but did not publicize it’s existence

The station really appeals to working class, blue collars in the eastern Massachusetts area.  Several callers dialed in their similar belief of the points above.

I think this episode marks some common perceptions of (web) programmers:

• They can accurately measure/estimate web usage
• They have the tools and know-how to make a site like this work
• Scale is not really a factor – they could have made this work
• Putting in a back door is just another hacking incident – they expected the site to fail, but wanted a way to provide access to selected insiders

Overall, it makes programmers sound very sinister; lacking morals; careless about the effects of their craft.

I wonder if the people that did this have any idea how badly they have maligned the industry.

Someone I know has been working on a death march project.  Management has refused to listen to reason.  Expectation of producing many thousands of lines of code per developer per week.  Team members attempting to jump ship before the death bell tolls.  Team members (developers) forced to sit through grueling team status meetings (in the light of these absurd delivery dates).  Really a very illogical situation.

Then I talked to a manager at another company.  The manager thinks they are ‘just’ setting up the subcontractor on the project to take a fall.  The upper management view of the project is that everything is rosy, on-time, on-budget, happy people.  But the bad subcontractor is not producing on time, budget, quality level per contract.  Yes, technically, the sub has been amiss.  Guess where all the fingers will be pointing when the delivery time slides on by without anything to show?  Once the sub is replaced then everything can be re-scheduled, budgeted, aligned, etc… 

I wonder how many times you can do that before upper management figures out where the problem really is?

I heard about a big software project that took a couple of dozen developers a few years to build.  The project had difficult security requirements that ended up having a login take over an hour to accomplish due to all of the verification between systems that had to occur.

The team went into a client review cycle knowing this was a big problem.  The client sat through the entire presentation and demonstration without a question.  Always a bad sign.

As the meeting was closing and everyone was gathering up their things one of the developers asked if the login time was a high priority or not.  (Duh!)

The client lead, while still gathering their things and not even looking up, said, “No.  We have a contract.  We will pay you for the software.  But, we are going to use something else anyway.”

Another contractor I know has been having a hard time.  Lots of experience in a team with very little experience.  Ok. Project lead has little experience and gets annoyed at the developer for proposing solutions or changes.  Not Ok.

I know there are lots of openings where he is working so suggested moving to another project.

He took the advice, waited for a milestone, and said something like “We are at a good breaking point.  I don’t think my contributions have been inline with the team.  Maybe it’s time for me to move on?”.  They said thank you for your idea.  Get back to work (not really).

Next day, team management calls him in and says “We would like you to take over architecture for the product.  This will entail much detailed interaction with the team lead.”

WTF?

We are in the midst of a Critical Design Review.  This is where we tell the client what we have done during detailed design.  All presentations are done in PowerPoint, no exceptions.  Whatever graphic, list, details, wording, etc… that you want to convey must fit on a PowerPoint slide.

We used UML during detailed design.  It is difficult to portray any meaningful sequence diagrams or complex class diagrams in a PowerPoint.  Other problems occur attempting to show a database design.  How to portray the 100+ tables in use in a slide?

Secondary problem is the level of detail provided needs to be discussed at a business case level.  This means talking about why this function/feature is of any interest to an end user, what is the benefit, etc…  BUT be prepared to drop down to an absolute bare bones detail discussion on any relevant area of the design.

One of the long-term employees (that really doesn’t narrow things down much, most employees have been there at least 5 if not 10 years) showed me some presentations for previous projects.  Yes, they all fit nicely onto slides.  Yes, they are ugly.  Yes, they remind you of 1950’s billboards ‘New’, ‘Improved’, ‘Zap’, ‘Zoom’, lightning bolts, you get the idea.

Another nugget from the contracting world: automation is expensive.

Automation is hardware and/or software that performs a human task.  It is usually expensive if done well.  Since it is hw/sw it is a capital investment of the contractor.  This investment is expected to be re-used across clients over time.  You can not allocate capital expenses against a contract.

On the other hand having humans perform a task is direct labor which can be applied towards a specific contract.

In the commercial software world a big automation impact (on team performance) is usually regression testing tools.  Such a tool can run through hundreds of regression tests in the time it may take a human to do one regression test.  The software developers usually have little qualm over the cost once they look at the ROI.

However, in the software contracting world, you can’t.  The customer foots the bill at all points.  The only reason you exist is for the contract.  The idea of investing for beyond a contract gets a glazed look in the accountant’s eyes (versus it usually being the other way around.

Seems like we need a new way of looking at micro-economics in the software contract world.

I have been going through the process of building a Joomla web site for a client.  I don’t think they had outrageous demands for the UI design.  Lots of fonts, colors, a few popups.

First off, tinyMCE by default “cleans up” your edited content.  This might mean stripping HTML tags, changing HTML tags or even better adding in a few extra HTML tags.  Really quite a feature.  So, now your very elaborate content ‘article’ has been manipulated badly by the article editor, it needs to be displayed.

A typical Joomla installation might have 10 CSS sheets, all of which are in play and possibly touching each other on a given page.  This makes it real fun to figure out really simple things, like how to set the width of the page.

Now, we add in the editor manipulated content that needs to be displayed with several bogus style references and you end up with total c _ _ _.  You have close to zero chance of figuring out why your content changed line height, font, indent, color, you name it – right in the middle of a paragraph.

I blame all of this on the cute idea of using table-less layouts via CSS.  That ideal means that people have gone to the next step and are using CSS everywhere.  It kind of reminds me of the first round of C++ programmers in the 80’s.  Everyone was doing it with no grasp of the underlying object oriented concepts needed.  So, we ended up with very hard to determine memory leaks in all kinds of programs (from simple apps to MS Windows).   I think the same thing is going on now, everyone is using CSS without any idea of the fundamental style concepts involved in the base HTML entities.  And we end up with the same mangled set of code which has very little hope of being displayed correctly.