Which is worse?

November 20th, 2008

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.”

Uncategorized ,

I Don’t Have an Ego

November 7th, 2008

Microsoft CEO Steve Ballmer said emphatically that his company will not make a renewed bid for Yahoo. His comments come after Yahoo CEO Jerry Yang said yesterday that Yahoo, which spent months dodging Microsoft’s bid, is now their best option.

Yang said he remains open to selling Yahoo at the right price, adding “people who know me know I don’t have an ego about remaining independent versus not remaining independent.” Ballmer left room open for future partnerships based on the two companies’ search engines, but was definitive on the point that Microsoft does not plan to acquire Yahoo.

With no Microsoft bid in sight and its Google partnership dead on arrival, Yahoo has reached what many analysts conclude is a strategic dead-end.

Why are Yahoo shareholders so in love with this guy?

Uncategorized ,

Did you hear me?

November 6th, 2008

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?

Uncategorized

Why do New things break Old things?

November 5th, 2008

For one of my clients a certain feature was broken that had been working fine for months.  My initial reaction was that the front-end changed.  Upon testing I tracked it down to a session variable no longer being set during login.  It turns out in the conversion from username/password to SSO a number of session variables were no longer being set.

For another situation a database job that had been running for some time on the first of the month apparently stopped working.  Upon investigation, the job had been completely removed from the system.  This was done when another client’s data was moved onto the database server.

In both cases New things, that are good ideas, were implemented in such a slipshod manner that existing, functional aspects were trashed.

Thinking about this some it seems like this is a very common occurrence: the developer of the New thing has the priority of getting the New thing done.  Old things take a distant second in anyones mind - developer, pm, client - anyone.

I know you can use a regression test suite to verify you didn’t break something, but this is an afterthought.  It is not in the developer’s frame of mind to determine what else might be affected by the New thing.  From my own experience if you happen to think of side effects you get looked at with squinted eye, not a team player, naysayer, problem child.

Further, fixing the broken Old thing after the fact is also looked at as a good thing.  “Yes, we fixed the Old thing.  It turns out the New thing broke it.”  Everyone is happy that the Old thing got fixed.  No one asks why this wasn’t discovered beforehand.

You can see this on software developer web sites.  Everyone can develop something New for you.  Or even more interesting they can debug your code or evaluate your system performance.  No one is advertising they will maintain your current system.  System maintenance is not valued.

Maybe this is just a trickle-down of the quarterly hockey stick affect working into how things get coded.  Imagine that, developers modeling their behavior after sales people.

Uncategorized

Your Replacement Starts Next Week

October 23rd, 2008

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.

Uncategorized

If You Want To Do Federal Work Learn To Use PowerPoint

October 20th, 2008

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.

Uncategorized

Stanford Offering FREE Online Programming Courses

October 9th, 2008

“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.

Uncategorized

Be Careful What You Ask For

October 4th, 2008

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.

Uncategorized

Automation is Expensive

October 2nd, 2008

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.

Uncategorized

Can we Delete Cascading Delete?

September 18th, 2008

I think we have a fairly standard database that looks like a parts BOMB.  Someone had the neato idea to use cascading delete in the project.  Hibernate’s cascading delete will follow any required foreign key and delete the children it finds there in a cyclical manner.  Good idea, huh?

No.  This means parent entity Parent with a primary key of ParentPrimaryKey MUST cascade it’s primary key to all children.  So, entity Child has a primary key of ChildPrimaryKey PLUS ParentPrimaryKey.  This continues all the way down your entity tree.  This example assumes simple row id’s for primary key.  If there was some other overriding attribute which makes every primary key a composite, like SystemThatThisEntityLivesOn, then every level has one of those plus all the parent’s.

Then we realize, we can’t actually delete some of the lower level entities because they are a lot of work to create.  So, we configure Hibernate to stop at those entities.

Now if we step back and look at the entity diagram for our database it is not uncommon for an entity at a lower level to have close to 20 component parts of a primary key that have cascaded down.

But, we only delete via cascade a very small subset of the entity tree.

Now, throw into the mix some developers who don’t understand the above features of a relational database or Hibernate in general and we now can’t use the LowLevelEntityId composite object that Hibernate generates as that is ‘unclean’.  We are to flatten all of these id’s wherever used.

Uncategorized , ,