Pencils Down

The words a contractor does not want to hear.  I know the company has a full-time need that I can’t support, but it did feel better knowing that there was a gap.  I asked about the new guy. 

Oh, he’s an old friend.  Lots of C/C++ work on Unix.  Some Oracle work.

But, the shop is all Java against SQL Server.

Oh, don’t worry about that.  He’s a good, long-timer.

Any web work?

No, but that won’t be a problem.  (The shop produces web applications)

How about he works on the current software to kind of see how things work?  That’s mostly SQL work at this point.

No, we were thinking he would jump in on the new product (A Java Spring app with every bleeding edge Java tool known)

Great.  Sounds like it will be a perfect fit.

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.

“This fall, SEE launches its programming by offering one of Stanford’s most popular engineering sequences: the three-course Introduction to Computer Science taken by the majority of Stanford undergraduates, and seven more advanced courses in artificial intelligence and electrical engineering. ”

http://see.stanford.edu/see/courses.aspx

This seems fanastic to me, but I’m just a hack.

So, at the big software contractor we are relying on another team to produce a library for accessing the database.  It should just be Hibernate, but that is another story.  The other team took quite a while to get up to speed on the task which made our project late.  We decided to live with Hibernate for now and switch over to their library once they are done.  We put in for a budget increase to account for doing this twice, once with Hibernate and once with the new library.

The accountants looked this over and thought: why not just wait for them to be done and do the impementation once.  This means our project is pushed out 3 months.  I guess our team at 3 months was cheaper than doing things twice.

However, we aren’t a tiny team so that means our budget gets bashed.  That means we can’t hire into the team.  That means our project is probably in jeopardy.

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.