Pencils Down

I think we have all evaluated a proprietary product, whether it’s something from Microsoft or a company you never heard of, but has the product you need.  The basic idea is to reduce risk.

• 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?

Wikipedia defines ageism as “stereotyping of and discrimination against individuals or groups because of their age”.   I know we all think we are still the hotshot twenty-something programmer just out of college, but reality is a little different.

There is a programmer on our team that has 20+ years into the company. Unfortunately, most of that time was spent on archaic versions of C on non-standard operating systems. BTW, the system in question is still in use in the field.

The problem came up when she transferred to our team. We are all Java, fairly leading edge type of stuff. She had a very hard time coming up to speed. It got to the point where she has been placed doing non-programming assignments for the team.

I think this has more to do with her age than anything else. I know she is just as much at fault for not keeping up with the industry, even as other projects in the company started to embrace Java. I also think the company is at fault for not pushing her in the corporate direction sooner.

So, now, on the surface, it looks like an older employee is being pushed aside. It sure smells a lot like ageism.

It occurred to me the other day that a big project is doing the Wrong Thing the Right Way. So, their process is great, but the project is dying off because they are doing the wrong thing, e.g. not meeting performance goals.

You would always like to be on a project doing the Right Thing, the Right Way, but I don’t get the impression that happens very often. I wonder if it’s just a matter of resources. Upper management is in the typical three-point dilemma: time, resources or features and skimps on at least one.

To fill out the matrix you can be on the Right Thing being done the Wrong Way. This would be a good project, but you aren’t following any rules. I think many successful companies work this way: get it out the door, now!

Then there is the worst case: Wrong Thing the Wrong Way. This kind of project is a killer: try as hard as you can and nothing is ever correct. Worse I think such projects put a big scarlet letter on you for the duration of your employment at a company.

As you would expect it is fairly common on larger projects in the defense arena where multiple tiers of subcontractors are used as needed.  Sounds good.

However, it appears that the typical subcontractor has no experience or skill in the subcontract that they have been awarded (I guess lowest price keeps winning).  Examples I have seen recently:

• Subcontractor making authorization wizard is basing the algorithm on the availability of ADSI.  However, ADSI will not be available on the target platform.  LDAP may be available.  All parties are aware of this but progress and time-lines keep moving on.
• Subcontractor responsible for lower level protocol handling in a secure environment has no expertise in networking or cryptography.  Subcontractor has to ask for designs from lead contractor so they can make any progress.

These subcontractors are making a lot of money doing the wrong thing or the unknown thing.  I don’t think its supposed to work this way.

Our company is teamed up with another big defense contractor on a project.  This appears to be a standard operating procedure for the DOD: hire multiple vendors bidding on a project and make them work together.

The project is mostly software.  So, it stands to reason that one team might provide re-usable widgets that the other should re-use.  The emphasis on “should”.

One widget wraps Hibernate as to be non-usable:  All queries must by static, lazy collections are not supported, session is not exposed, etc… That type of thing.

So, the other team has to “prove” that the widget is unusable.  Our team is small.  Two people have been spending easily 50% of their time for a few weeks proving their case.  Also, need to account for unknown amounts of politicking occurring at management levels.

It’s still not settled.  I don’t think it will ever  be settled.

We have a younger guy hired to do graphics.  He is pretty good.  We have a regular need for graphics design or other.  Seems like a pretty normal thing.

However, as little odd jobs have come up, he was somehow determined to be lower on the totem pole and allocated for these jobs.  Not graphics or even computer stuff – put a chair together for a new developer, put up office panels for the new COO, put the coffee cups into the dishwasher, put up whiteboards in some of the offices.  It’s not like any of the people that were getting these things done were handicapped.

Then there were the ‘computer’ tasks as well: gather all the emails we recieve from a client and look for any emails that were not recieved, manually perform some programming step a few hundred times to determine what the error was, evaluate a list of 100K names for duplicates.

He has been here 10 months and just gave notice that he is quitting and going back to live with his mother.  Think about it, when you were 25 how bad would things have to be to agree to move back home with mom?

I wonder if Employee Abuse is a punishable crime.

We have a client that uses codes to organize their user hierarchy.  They are consistenly re-using the same codes for different groups of people, concurrently.  This, of course, wreaks havoc witht the user access layer as it tries to determine who-is-who.  The lead developer has explained the problem and possible solutions at least a dozen times to the customer reps over the last year or so.   And it happened again today with the follow on question from the lead developer about when this might be fixed and the automatic response from the customer rep as to why this is a problem.

It would be nice to be able to generate an automatic response (both from the customer rep and the lead developer) in this situation.  The neatest piece would be having a meeting auto setup between the lead developer, customer rep and the CTO so the thing could finally get resolved.  The bad thing is the customer, who has been in business for over a hundred years, is extremely unlikely to change their ways regardless of what we do.

The whole thing reminds me of the story of a comedian convention where commedians would catch each other in the hall, say something like “Joke 43″ and both would start laughing.  At least they both found it funny.