The Joel on Software Discussion Group

There is a potential client that contacted us for office technical support. As part of thier "pre-bid" process, there we go through a multitude of security checks, proof of competency, etc. and we have to be familiar with this program. If we aren't able to support Pick, then we aren't an elligable bidder.

I did some digging and this looks like a really ancient system. Is it that hard to support? No big deal? Run away? I can't find any sites with much reference material to read up on, either. I'm tempted to just walk away from the client but they are pretty big and they could be a good client.

Any thoughts?

PICK is a database. Most of the people supporting this are the sort that have a lot of facial hair and wear suspenders. I've mostly seen it on mainframes.

Wikipedia has a LOT more info on it:
http://en.wikipedia.org/wiki/Pick_operating_system

I work on a Pick system for a client here in Anchorage.  And I worked in Pick in the 80's at ADP Dealer Services in Portland.  At that time it was an operating system.  Since then, they changed it to run on top of Windows or Linux.

It is more than a database.  Users are managed in it.  Programs are written in a Basic sort of language.  It is not something you could pretend to know and get away with.  Supporting it is not easy either and there's no good documentation.

You might try advertising in Portland to get someone away from ADP to work for you.  Otherwise, I would walk away.

Wow what a cool read, talk about Legacy system......

They specifically mention Pick Operating system. They haven't given us much detail about what they are using it for. The Wikipedia has a couple lines I love:

"The first commercial release was in 1973"

"The resulting fragmented plethora of non-standard implementations caused the various Pick systems to wander ineffectively"

It doesn't exactly fill me with confidence...

The best bet is to try to locate a PICK programmer or two to subcontract that work to:

http://www.google.com/search?hl=en&q=PICK+programmer&btnG=Google+Search

Note the Adsense ads and multiple hits for resumes.

BTW Pick is one of those crusty old technologies that are still in surprisingly wide use.

A gold mine for those few consultants who actually know how to work with it.

We're in the process of doing a huge migration from a PICK backend to an SOA/.NET architecture where i now work (health insurance business).

PICK is a multi-value database. read: _not_ relational. was invented by some dude in CA in the 60s initially to catalog chopper parts for the US military. PICK is all files-based. PICK is a nightmare and a bit like sea urchins. If you're gonna mess with them, you better damn well understand what you're doing.

>It doesn't exactly fill me with confidence...

You have your answer. Decline the business. Keep in touch in case they ever drop Pick.

Where I used to work, we had Pick on top of Solaris.

Having spent years working on pick systems, I can tell you they are really amazing systems.

Prime Information, Advanced Revelation, Ultimate and a few others are really pick licenses.

It is rather ironic that a system that stores data in delimited strings is being criticized as being old. In fact, the pick model is the basis for xml. They are nearly IDENTICAL in their ability to store repeating data in a string. Furher, currency data (number data) is actually stored on disk as ascii text…again, just like xml..it is text data…not binary…

In the hands a seasoned developer, those multi-valued systems are REALLY REALLY amazing.

As for them being non-relational, well, that really a point of view, and a physical one vs that of a logical view. Virtually all multi-value database vendors (including pick) now have support for sql. And, that sql works on the EXISTING databases. What that means is the pick multi-value model can be EASILY  mapped to a relational sql model. So, if that model can mimic sql tables, then it for all purposes is relational (at least when you make it quack like a duck).

If you understand how these systems work, then you would not really want map the tables to sql tables anyway. However, for migration purposes…it very well makes sense to do that.

I written a TON of software on pick s systems. And, I have nice article here as to what it took to convert a pick application to sql (in this case, it was ms-access), but the lessons here are VERY valuable, and I suggest you read this article of mine, as you learn some of the issues that you will encounter:

http://www.members.shaw.ca/AlbertKallal/Articles/fog0000000003.html

As for leaning the pick system? Golly, you think your going to learn Visual Studio and c# in a week?  You think you can learn the Oracle system in a week, and then learn pl-sql (the sql language in oracle)? I not even going to begin to entertain this.

Further, you have completely new conceptual data model to learn, and it not a relational model. That whole setup takes time to learn and it is a complex mainframe system. And, you have to learn to THINK in multi-value.

However, once you learn the system, then it becomes a model of simplicity.

Do NOT kid yourself, you not going to learn how to support such a system in a week…let alone a month…. Sorry, it not going to happen.

Anyway, like any legacy system, some code is horrible and ugly. These systems often date back to the 1980’s…and some even earlier.  Remember IBM was not pushing sql until the early 80’s. And, IBM was pushing structured programming in the late 70’s…when pick had been out. And, the code writing utilites for pick remain weak to this day.

However, pick had a nice non procderual query language (similar to sql), and a nice programming language consering the time period. The language is much like the older FoxPro or dbase language. Perhaps even a better analogy is a business basic lanuage. However, compared to the wangs, or Altos, or other systems of the day..the pick BASIC lanague was considerably nicer. And, pick is a p-code runtime system just like java (hey, delintned text like xml to store data, and p-code runtime…gee…you think this was the lastest system on the block!!!).

I have a article I written as to why I think those systems are so terrific here:

http://www.members.shaw.ca/AlbertKallal/Articles/fog0000000006.html

At the end of the above article I have links to the major vendors of multi-valued systems. Note that pick is now called Raining Data.

You WILL need to retain some pick expertise to help in this migration…simple as that…

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com

Once again:

The problem is that Seattle MCSE wants this business but this one technology to which the client is committed stands in the way.

Business wise, and nuts and bolts aside, Seattle MCSE should shop for Pick subcontractors and should determine what sort of pricing and service commitments are necessary. Such folks appear to be plentiful, from first indications.

Regardless of profound technical merits, people who know and work with legacy systems like Pick tend to be hurting because the billable work or jobs are scattered and difficult to locate. Also remember that this industry ostracizes anyone not in the mainstream, which precisely characterizes someone who is proficient in Pick. Staffing should not be a huge problem.

It should not be difficult to find some compatible candidates who could fulfill that aspect of a support contract.

My first job out of college was working on a Pick variant system.  I did that for 3-4 years.  It had its good points, but it is pretty crusty technology. 

I would either look for Pick subcontractors in your area, or possibly consider whether this is a client you really want, if they are so committed to sticking with Pick.

Its is key whether they are running the Pick operating system or just a Pick / off shoot database running on a more widely used operating system.

If it is a Pick operating system and your not familiar with supporting legacy type hardware / software then walk away. As an example of what you may face consider the possible need to have an operator on a night shift doing a backup and swapping 10 pound tapes onto tape drives.

If its just the database variant then get a subcontractor. Is there a former employee of your possible client available?

Is the customer capable of telling you which it is? Verify for yourself.

Thery're not saying, unfortunately. They are (in effect) saying "If you don't know what it is then you obviously can't support it".

Unfortunately, they want a single source support company - no subs. I don't know why they want that, really, since that requirement is going to seriously cut the number of potential providers. We will probably have to walk away... pity...

Thanks for all the responses.

>> They are (in effect) saying "If you don't know what it is then you obviously can't support it".

That's a good time to walk away. You've just saved a lot of pain down the road :)

"...a bit like sea urchins. If you're gonna mess with them, you better damn well understand what you're doing."

simultaneosly amused me and made me want to learn about sea urchins.

>> they want a single source support company - no subs.

Let's be abundantly clear: any contract that the client signs is with YOUR COMPANY, not with individuals on your staff. THAT is the single source. THAT is how you present any proposal.

Example: if you have a house built, you sign a contract with the builder, NOT with the electrician or plumber who work under him. The builder takes responsibility for the overall result and even for the individual components. If the electrical work isn't correct, the builder finds another electrician, they don't come to you and ask you to approve of a change of sub.

In my own business this is an important distinction that I have to deal with myself. My client may expect that I provide all deliverable work personally, but I have from time to time needed to bring in a subcontractor to deal with some technology that I had little experience with. If my client objected to this, then I couldn't provide the service.

If the prospect treats dealings with you as a bunch of hand picked individuals that they have veto power over, then the prospect really wants to treat your company like a single temp employee or like a temp staffing agency. My assumption is that like any end user, your prospect doesn't even know how to look for Pick people.

A "rule" like "no subcontractors" is basically saying that they want to pick bodies to work on their stuff but have the bodies be legally employed by someone else. They want temps, they should go to Manpower.

In this instance, assuming that I could work with the client, what I would do is solicit opinions from Pick contractors. I would present any findings in my proposal.

But the prospect has absolutely no business telling you how to run your business. THAT is the deal killer. NOT that you personally don't have Pick.

"But the prospect has absolutely no business telling you how to run your business. "

Well, I disagree. Sure, they can't tell you exactly HOW to run your business. That is completely up to you. But they are well within their rights to say no to a company whose proposal includes contractors. Would you sign a multi-million dollar deal with a guy who worked out of his basement and "promised" to make sure that he had contractors on board to handle the job? I wouldn't. Now that is an extreme example and probably far from the current scenario but a customer is a customer and they have the right to at least understand how you intend to support them. After all, you could just as easily be telling them that you intend to subcontract the support out of India or MugoChafPissKistan (wherever that happens to be).

Let's turn this around. Suppose Seattle MCSE had an employee on staff who knew Pick and who would participate in a bid for this project. So the prospect accepted the proposal and a contract was signed. But employees are not slaves. That employee leaves. Now, Seattle MCSE's company is "not qualified?" I don't think so. What they are obliged to do is provide continuity to the client by identifying and hiring another Pick guy or gal.

Many top tier consulting companies do the sort of irresponsible outsourcing of key deliverables to nameless contractors that you describe, every day. It is often the little guys who deliver what the client actually needs.

The guy operating his business out of a spare bedroom may have the actual applied wisdom necessary to identify and deploy a solution to the client's problems.

That wisdom may include the ability to network and to use search tools, and to interview, to find a subject matter expert who would be brought in under the umbrella of the main contractor.

I'm saying that the responsibility for encapsulating the support for everything that the prospect needs is the responsibility of the main contractor.

The prospect probably doesn't want to HEAR that there is a subcontractor. They want to feel confident that this is a single source solution.  Anyone with a reasonable business structure and the actual ability to produce a worker with the needed skills can do this.

I agree that it sounds reasonable. I'm just saying that it is well within the rights of the client to say that no contractors will be used. It is their right to request this in writing as a condition of getting the deal. And the OP is well within his rights to tell them to just "stick-it" as well.

So saying that a client has no right to request this or has no business knowing about how you run your company is what I'm arguing about. I agree that letting the OP decide how to handle support may be best. But the customer has their own thoughts about how they want to be supported and it is not unusual for companies to put specific staffing clauses into contracts.

Case in point, more than once we've signed contracts with a client which stated that we would keep at least two programmers on staff at all times who understood their system. If someone leaves then we are obligated contractually to hire a new programmer and spend time training them. Now we could have refused to do this. But you'd best believe that we would have lost the sale in the first place.

So customers can do whatever they want as long as you are willing to let them. This includes telling you who will work on their project, for how long, and what time schedule they'll keep. And you always have the option of telling them to stick that contract where the sun don't shine. Whether it's the "best" way to structure a new deal/relationship is an entirely different discussion.

You know, I just had a idea - I wonder if they were just trolling for proposals so that they could show to management that thier current supplier was still cost competitive? It hasn't happened to me in a while so maybe we missed a sign or somethng...

Meh... no big loss I guess.

Dood,

Just a question: how would the client even *know* that contractors are involved? For instance, suppose the contractors signed NDAs and non competes that required them to identify themselves as employees of the prime contractor.

I see what you mean about the implications of agreeing to provide continuity of service to the client and I agree that this is where it leads. I am just saying that the same issue applies no matter where the service provider is starting from - whether they have had a Pick person on staff already, or brought them in just for this project.

Realistically, the potential cost and liability of staffing and covering a role for someone who works with little used niche technology is probably not appropriate for a smaller solution provider.

Business issues completely aside:

I'll make a guess that the OP's prospect had a long term "do everything" person on staff who knew Pick and who kept everything in terms of computers running. Then that person retired, quit or was fired. They want the same kind of deal, again.

"Just a question: how would the client even *know* that contractors are involved? "

They wouldn't. But if it went to a court of law they'd be in trouble. So the OP would be taking a risk by not holding up is end of the bargain.

"Realistically, the potential cost and liability of staffing and covering a role for someone who works with little used niche technology is probably not appropriate for a smaller solution provider."

I absolutely agree. In our case one contract was to support a custom solution written for the customer by a company that went out of business. We were big enough that we already had developers on staff that we could commit to it (many of them were twiddling their thumbs anyway). And the numbers were good. We more than covered our costs and the deal was very lucrative for us. But for a small service company, bringing on real employees to cover such a deal could be suicide. If you can go the contractor route then that would certainly be less risky. But if the customer won't go for it (assuming they even have a preference) then I don't know what else you can do. At that point I'd probably walk away from the deal if the numbers aren't substantial enough.

"I'll make a guess that the OP's prospect had a long term "do everything" person on staff who knew Pick and who kept everything in terms of computers running. Then that person retired, quit or was fired. They want the same kind of deal, again. "

I hadn't considered that but it is a very likely scenario. That could also explain the preference for a full time employee to be on the service provider's staff.

>> "Just a question: how would the client even *know* that contractors are involved? "

>> They wouldn't. But if it went to a court of law they'd be in trouble. So the OP would be taking a risk by not holding up is end of the bargain.

Dood, the terms "employee" and "contractor" are pure semantics. I know that you believe otherwise. Again - and not to be a contrarian PITA, because this has been a good discussion - I am simply pointing out that ALL "human resources" are basically contingent labor and are not guaranteed.

I'll extend my example of using a contractor even farther. A consulting shop could hire a *W2 contractor*, that is, an employee who is hired on an hourly basis and has taxes withheld. This is an extremely common working arrangement for contracting houses.

So that person could be an employee, yet hired only for this one purpose. And cut loose if the opportunity ceases to exist.

In this context I think we both know what the client probably wants. I am pointing out that there are some perfectly acceptable ways for a service provider to support the client's functional needs while not necessarily honoring the spirit of the client's wishes in all respects.

Another possibility is that the prospect has already settled on a vendor, that they've made this particular issue a requirement because the vendor they've already selected has a Pick programmer on staff, and that this is all being done in the service of some kind of internal political process that only the prospect knows about.

That said, here's a little more love for Pick, which was just the best thing going in 1987 or thereabouts.  It's a little overenthusiastic to say (as someone did above) that Pick was the basis for XML; Pick's hierarchy of multivariate strings was defined in a much kookier (though less space-intensive!) way than XML's.  Like XML, it was conceived of as One Data Structure To Rule Them All.  It had a lot going for it.

Particularly at a time when the rest of the world was settling on DBase III.  Sit down behind Advanced Revelation and figure out how it works and it's like entering some kind of crazy alternative-universe view of what the future could have looked like.

Oh, and:

> In the hands a seasoned developer, those multi-valued
> systems are REALLY REALLY amazing.

True.  And in the hands of an incompetent one, they could be turned into the most horrifying WTF you can possibly imagine.

>It's a little overenthusiastic to say (as someone did above) that Pick was the basis for XML; Pick's hierarchy of multivariate strings was defined in a much kookier (though less space-intensive!) way than XML's.

When I say basis, I don’t mean that the xml people went to look at pick..and said..ok, lets copy this. (I did not intend to miss lead on this issue - my sorry!)

What I do mean however is that the BIG revolution in xml is that fact that SINGLE string can represent some fields, and also some REPEATING data fields.  (it can have BOTH TYPES of fields…..repeating data…and NON repeating data in the SAME structure). This concept is central to the success of xml.

It is the above data trait that makes xml so useful (*both* repeating and *non* repeating data can be in ONE structure). This is why it is used in web services (you can send a invoice as  string, and that invoice can contain several sub-tables of *repeating* data in addition to the main company informant).

The fact of using html <tag> commands, or a character delimiter like pick is a moot point. Any developer using xml will use a library of code that gives you are nice logical way to traverse, or pull values out of that data structure.  The developer never sees, nor users the delimiters in that xml. And, in pick…it is much the same (the programing lanauge supports using that data as a structuire).

The fact of using <tags> in html, or delimiters in pick is a moot point.

The xml library you use in code are VERY similar to the pick mv structure and how you manipulate it at the code level.

In fact, anyone who’s done lots of pick work will forever walk away with the idea that anytime you need to save some data “structure” in your code, it is super easy.

So, for example you need to save a structure that represents a data screen layout, you save that layout as a string on disk. However, that string is really like a delimited array, or a table of values representing locations of the fields. Pick was super good at this type of serialization of your application configuration data.

It is no surprise that companies like MS are going gang busters with xml everywhere. Even the customizing of the office tool bar is now saved as xml.  And, the new windows installers are also starting to use  xml for their configuration data. This simple data structure allows one to save, and retrieve these malleable structures without having to build a database table EVERY time is what makes xml SO INCREDIBLE.

Xml is exploding in use in the area of saving application configuring stuff. Apparently MS has figured out what pick people loved about multi-value data.
 
So, the explosion in xml is actually occurring on the developer side, and specific because it is WAY less work to build, save, store, and retrieve a data structure as a string as compared to using a database to save a few config things about your application. And, you don't really need a database to store the data either.

And, this is the #1 reason why pick was so good from a developers point of view also.

Developers don’t care if you use <tags>, or markup language, or delimiters like pick, as long as the developer can conceptually view the data as a structure they are happy.

It just so happens that both pick and xml do this the same way from a logical point of view, and also a physcial point of view.

So, the above is the thing that xml gets from pick that I was talking about. It may, or may not be intentional on the xml side to copy the pick concpet. However, this just means that the whole industry has finally figured out what was so great about those multi-value systems. The only thing was that pick had this for 30+ years now, and this whole concept is only now becoming mainstream.

Did I mention that the new version of JET for ms-access now supports multi-values, and again this being driven by xml….


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com