How difficult to get programming done on an existing software product ?

4 weeks ago I get a phone call out of the blue from a guy I’ve known of for 20 years. Similar business’s we have in the same industry although his niche and mine are different. He has health issues and wants out.

All things check out, the financials, the sales and marketing, the back office things. All of that I have squared away in my head how to do and continue on. My accountant and attorney have checked it all out and tell me no problems they are seeing in the way I would set it up.

My one issue is the programming as I would be taking over a software product. A niche product, no competitors, but none the less I will have to have programming done in the future.

In my current business I work on the other side of software not the programming side. I understand well the sales cycle, the implementation, customization, data requirements, and support. However in my time in the business I have never worked with the programming.

So my question is how difficult is it to take over control of an existing small software product and then find the programming to continue on ?

Entirely depends on the technologies used, if they’re common or niche. Something written in VisualBasic, probably easy. Something written in COBOL? Nope… Also of course depends on the documentation included , source code comments etc. There is so many variables involved. What you really need is to find a VERY experienced applications programmer you can trust and get him to do an evaluation. Offer to sign an NDA to the current business owner. They would need access to the entire source code for at least 3 or 4 days to make an evaluation.

Sql data storage and in C++

coremelt, your post is generally good advice, IMO, but I’m curious about why you think it would be difficult to make programming changes if the application is written in COBOL.

Can of worms.

It could be anything. Lots upon lots of questions.

Is there any business other than the software?
Who currently writes the software?
What is the customer base?
Is the software licensed? Sold?
What support is given to customers - what support contracts exist?

What software engineering processes are used?
Are they really used?
Documentation?
Testing?
Release process?
Bug fix process?
Upgrade process?

If everyone in the company left tomorrow could someone come in cold and work out what the heck was going on?

You are going to need help in making the decisions. Software businesses can go horribly wrong in ways you can’t begin to imagine if things are not under control. And that takes significant experience to gauge.

WAG, but it’s probably related to COBOL being old as dirt and repeatedly updated through the last ~50 years. It was developed by people in business and government without computer science input, which has made it…clumsy.
Cobol is -

[QUOTE=The Jargon File]
A weak, verbose, and flabby language used by code grinders to do boring mindless things on dinosaur mainframes. […] Its very name is seldom uttered without ritual expressions of disgust or horror.
[/QUOTE]

Who wrote the program in the first place? How does your friend currently maintain it and make improvements?

This.

Taking over control of the development of a product is hard enough when it’s been developed using best practices and standards.

If the product isn’t written to adhere to any kind of standard, and there’s no source control, documentation, etc, you might as well reverse engineer and rewrite from a blank page based on what it looks like and what it’s supposed to do.

I’m not coremelt, but I’d guess one reason is the difficulty of finding somebody who can do the work. COBOL isn’t a language taught much anymore, and there just isn’t a big talent pool available of people looking for jobs; the average age of COBOL programmers is somewhere around 55.

To expend on this (and I wasn’t kidding in any part, BTW).

If the product has been whipped up by a small (or one-man) development team with their own idiosyncratic ideas about best practice (‘opinion is divided on that topic’), you will spend about the same amount of time (and more effort) getting to know it, getting up to speed and understanding how it’s built, as you would spend just writing a new one.

Also, at the end of that period of time, you’re only up to speed - you’re not any better off; you haven’t resolved any problems and you haven’t added any features.

Look before you leap, is the best advice. Don’t commit to shining it up until you’ve found out whether it’s a gemstone or a turd.

It can be done but can be challenging.

In my 30 years in software, I knew quite a few talented software engineers who should step into other people’s code and maintain it. Some specialized in that.

Others would throw up their hands and want to rewrite it. (Not a good thing)

Ideally you would find one of the former and have them work with the current guy for a while to get up to speed. SQL and C++ are pretty common skills - not exactly cutting edge these days but you should be able to find good programmers easily.

If you know anyone who can do some technical due diligence, do so. At least as important as having your accountant and lawyer check things out.

I worked as a programmer, primarily using C and C++, for ~20 years. We’re not hard to find, but it’s easier to find someone who thinks he’s a good C++ programmer than it is to find a good C++ programmer, so that’s a concern. C++ has fallen somewhat out of favor in recent years, but it’s certainly not dead.

Do you have any idea how many lines of code you’d be taking over? Lines-of-code is a decent enough indicator of the complexity of the code for message board talk. Obviously, though, a thousand lines of code for a recipe cataloguing system is easier to maintain than a thousand lines of code for a custom numerical analysis application running on a parallel processing platform.

And speaking of platforms, is this a Windows application, or something else? That will make a difference in how difficult it is to find someone as well (and how much you’ll have to pay them.)

I would say it depends almost as much on what kind of test suite exists as it does on the code.

If there are automated tests that can easily be run, it’s relatively easy and safe for someone to start poking around and trying out changes. The tests will tell you if something is broken.

If there’s no automated testing, then the first thing any maintainer should do is write a bunch of tests, both to characterize what the actual current behavior is (probably not quite the same as what the intended behavior is), and to guard against unintended changes.

So you don’t really know him at all and he contacted you directly. Isn’t that a danger signal?

You are clueless about a key aspect of the business, so why are you not politely declining? If this guy has a staff of programmers then will you not be taking them over?

Add my voice to the chorus of people saying that it depends very little on the actual language/platform used, and much, much more on the attention given to maintainability, documentation, and testing during the original development.

Undocumented, untested, spaghetti logic is going to be hell to maintain no matter what it was written in.

An old business partner of mine took over a company in a similar situation. The business was going under, it had a few dedicated customers willing to pay to keep it going but not enough to keep the company afloat. So my former partner was handed the business for free. He later said he overpaid. He had the people to handle the software and support, but the software was a mess, the customers demanding, and he hadn’t acquired any real value. He ended up giving those customers a discounted price to get them to switch to his own software.

I’ve been involved in several software hand-offs of this nature in my own business. I would explain to potential clients that there was a high up-front cost to analyzing and documenting the software before it could really be maintained effectively. Except for one case, I was turned down at first and then asked months later to come in and start over the way it should have been done.

Perhaps you might provide more information about the scale of this business. Is this essentially a one person business (the guy who is leaving) or are there several staff? How many? How many lines of code are you talking about? How much revenue?

I’d second coremelt’s advice. It is impossible to know without having looked at the code.

When I’ve done this in the past, the first thing they pay for is an evaluation of the source code, under NDA. You get the source, compile it, run it and generally step through it to get the gist of what kind of beast you are taking on. The actual cost and time estimates for the work itself is based on that assessment.