So, they hired a designer on their own.  After selection I talked with the guy to make sure it wouldn’t just be a PSD as the output: he agreed.  Once the design was agreed upon he didn’t just give me the PSD, he gave me a bunch of PNG files that he cut from the PSD.  How nice.

Now we are going into week two of the process trying to get HTML and CSS out of him.  I don’t think he has ever done this before.  He is good at coming up with nice pictures with the right color schemes and fonts and the like, probably an art background.  He is just lost coming up with the parts of the design you need to actually develop a web site – HTML, CSS and Javascript for any widgets/special effects in the design (there are a few).

Maybe I am expecting too much?  Every other designer I have worked with has produced the initial HTML… layouts.  Maybe I have  just been lucky?

One of the forms invokes some tens of thousands of lines of SQL code on the backend touching a large number of tables and invoking a good number of stored procedures. In order to automate this someone on the web team has to understand all that code. Again, from a programmers point of view, doable – might take a while.

Ok, now how to explain the size, scale of the problem to someone who knows nothing about programming?

I threw out the idea of going to the library, reading a novel that was several hundred pages long and having to understand exactly what happens to every character portrayed in chronological order.

Thinking about that later I wonder if I was very far off:

• A typical page of a novel has 50-60 lines which equates to several hundred pages.
• A line of SQL does not correspond well to a line in a novel, but given the power of the syntax it may have as much meaning
• The chronological importance is important in both cases, more so for the SQL.

Maybe it’s not such a bad analogy to use.  Maybe even the PHB might get it:)

Now one of their own is leaving.  All of that assumed understanding over the years is showing up as a lack of communication and follow-through.  The developer leaving has been off the range for years:

• home grown web service – doesn’t like SOAP
• obscure database – has a neato auto-maintenance feature, but nothing else
• no ORM – it works much faster without it.  developed his own higher-level constructs like Expression builders.
• really extensive app server – but there are just customers, orders, etc… in there.  what is all this code doing?
• ignored the selling product – it uses MySQL, how yucky.  it’s mostly a Swing app, how uncouth.

Worst of all management had no idea what this guy was doing.  When they asked about interfacing some 3rd party app – he said sure, and started coding something homegrown.  When they asked about integrating the selling product – he said sure, and started coding the next homegrown section.  Piece after piece after piece.

What a nightmare.

I dreamed up all kinds of reasons that the issues existed.  This has usually been helpful in the past – try to come up with different scenarios before looking at code.  Try to visualize what the code is doing.  Got trained to do that somewhere along the line.

Once I looked at the code it was just wrong.  There was test coding around the edges that hadn’t been removed.  Fixes in place in 10 minutes versus time wasted visualizing.

Maybe I would be better off jumping into code asap?

Similar story with another client.  Should be mostly a re-skinning project.  Mind-numbing change 1000 references to widget x to widget y.  Estimates given are based on common practice – how would someone normally code such a thing?  what kinds of re-use would be involved?  how to account for configuration changes?  Again, the visualization thing.  Finally look into the code and your head explodes.

I should know better.  I have been programming for a long time.  I think people generally do a good job but pressures are always in place to get it done faster.  Hence the name of this blog (See About).

What is your approach?

• How long in business? profitable?
• How popular is the product?
• Size of company?
• Release schedule?
• Bugs/issues?  How quickly resolved?

But in these times it is likely that an open-sourced product does what you need.  There are likely even several versions from different vendors available.  Some vendors very large and well known, others one-man shows.  You search on google for the product and get 500,000 hits.  What do you do now?

The idea is still to eliminate risk.  I think you have different concerns though:

• How long in business? profitable? – don’t really care.  there are plenty of people out there working in this solution, you have the source, you can get someone else to fix it.
• How popular is the product? – probably not an issue.  yes, this particular vendors implementation varies, but quite a number of people have experience working on this
• Size of company? – a question of long-term ability.  again, there are quite a number of other people out there who can help
• Release schedule? – it would be great if you saw a steady stream of development, but this is unlikely.  the spec defining the open-source tool has probably been around for a while and there really shouldn’t be much of a need for updates
• Bugs/issues?  How quickly resolved? – probably when first released there was some furious coding, but after a while it should be stabilized

So, how do you do this?

I think you can look at it like hiring a remote contractor:  You need someone to help out with implementing a well-known solution and want them really to go away afterward.  Maybe call them once in a while if you turn on some other feature in your product and don’t remember what steps are needed.

As such, some concerns you want to know:

• Responsiveness
• Experience in the area
• How much other (not in the product you care about) work do they have?
• Any skills matching up to your developers (Java, C#, database, etc…)?
• Are they using the open-source code in a retail product they are selling?  Self-interest is always the best motivator

How do you evaluate open source software?

Thinking about this I looked at what would need to happen if we changed one variable:

• If you reduced Resources then you would need more Time or less Features
• If you reduced Time then you would need more Resources or less Features
• If you increased Features then you would need more Time or more Resources

But thinking about this, changes in Resources usually make no difference in the short term.  Adding another developer does very little until the developer comes up to speed.  Depending on their expertise this can take a while.  So, what if we treated Resources as a constant?

We end up with a relationship like: Resources = Features over Time (R = F/T).  Sounds really pretty nice.  Kind of makes sense.  Can be looked at as a productivity measures, quality measure, etc… as well.  Again you don’t expect the productivity of your team or their quality level to change much in the short term.  Walking through the cases above we get relationships to still work.

I think this is a nice clear mathematical argument even the most demanding manager can understand.  Oh, you want to increase Features this late in the project.  That means we need more Time – see here…  Yes, we can increase our productivity, but not in the short term (phase) of this project.

It never worked.  Tried replacing various components about 6 times.  Finally returned the whole thing to the store.

At the store one of the clerks mentioned, “Oh, yeah.  Those don’t work a lot.  Be thankful you didn’t buy an XBOX.”

This prompted my curiosity, “What do you mean?”

The clerk said, “Oh, the XBOX’s fail about 75% of the time”.

Being in software I was a little flabbergasted.  “How can that be?  These are extremely popular items; that YOU sell.”

“I just work here.”  Realized he had revealed too much and proceeded to hush up for the rest of the transaction.

Being in commercial software I have lived through the horrors of bugs in software that persist well past the FCS date.  Some of these can be fatal, most are doggedly consistent errors in logic that just mess things up.

Maybe I am being stuck up, but the game software DOES NOT START!  This is not even close to an FCS quality level.

Do game software writers not work in the same realm as the rest of their brethren?  Are they immune from the QA/QC police?  Management/marketing breathing over your shoulders about typos and nits they found over the weekend?  Heaven forbid your application does not start, boot, begin correctly for them in whatever strange configuration they manage in their household.

The more you think you understand something the less you actually know.

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.