Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We are in the process of auditing a company with a view to buying them out. One of the key parts of this decision is the software they've developed over a long period of time. We always have the option of building our own, but we are all aware that it could take us longer to get operational if we build from scratch.

My question is rather specific: I come from a development / PM background, and have been asked to do a full audit of this company's software, which is a web application. We want to know as much as possible about it before we make the decision of whether to buy them out, and after a basic demo, their system seems to do what we want, but we know that we'll need to modify it to a certain extent.

I am looking for a template or framework to work through in order to produce my final report. Its been really tough finding anything through Google; most of what I've found is just basic checklists at best. I would need a template or framework that deals with infrastructure, design, architecture, hosting, etc.

Has anyone had experience with this? I would be very grateful if someone is willing to share their template/framework with me.


migration rejected from stackoverflow.com Oct 22 '13 at 1:02

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by gnat, MichaelT, Kilian Foth, World Engineer Oct 22 '13 at 1:02

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, MichaelT, Kilian Foth, World Engineer
If this question can be reworded to fit the rules in the help center, please edit the question.

There are businesses that provide this service so they are not going to publish their checklists or processes for anyone to see. You are lucky they are allowing you to do audit, most companies would insist on a independent third party audit so you can't see their IP –  james Oct 11 '11 at 14:22

5 Answers 5

In the absence of frameworks, and given the response you have had so far here and on “startups” there don’t seem to be any, you might try a different approach. Get the answers to the questions you see as key, say current risks and future costs and then convert them to a crowd pleasing document. We’ll assume your commercial colleagues will take care of product profitability and development cost effectiveness.

For my money: current risks should cover security (is there a regular application security scan? What internal controls are there?), technology (does the application depend on software or infrastructure that is no longer supported), intellectual property (are they on the bleeding edge - is license-contravening code in use? Are patent trolls waiting to pounce?) and continuity (are there disaster recovery provisions? What is the trend in the number of operational and development issues? How near to capacity are the servers running?).

Future costs arise due to inevitable change. Change in the market or business model, change in technology (e.g. hardware or software becoming obsolete) and most importantly change in the development team. Good development practices such as continuous integration and unit testing are an indicator of strength here. The full list of good practices is long and can be readily found for most technology stacks on line. If you get the opportunity, try maintaining some of the code - I can’t think of a better test.

Finally dependencies are the enemy and warrant an investigation of their own. Whether it’s the entanglement between layers of software, the knowledge in some developer’s brain, some binary for which the source is long since lost or some vendor with the whip hand, they are worth exposing and costing in your report.

I think this sort of exercise is worthwhile, with or without a framework. I envy your assignment and hope this piece has included at least one issue you would not have thought of.


Having been through one software buyout on one occasion and maintaining bought out software at a different company, I will say that my experience has been beyond reprehensible with both situations. The latter situation was the highest coupled, lowest cohesion, hacked feature, antiquated technology Frankenstein's monster of a software package I have ever experienced in my life. Technical debt doesn't even begin to describe the dysfunction of that software. It also didn't help that management was a cross between the pointy-haired boss from Dilbert and Mr. Spacely from the Jetsons, but that was a different issue altogether.

The situation where the team I was on had to evaluate existing software for purchase ended up opening my eyes to way these things typically go down.

We evaluated what minute scraps of documentation we could assemble, the supposed architecture that was in place, the absence of seperation of concerns, the lack of source control history, the lack of issue tracking and history of issue tracking, the amount of manual database and file system cleanup work that was being done on a daily basis to keep everything alive, the lock in to JRE 1.3 (don't ask, long story short, its true) and the failure to maintain licenses for third party software and modules regardless of GPL or proprietary (They couldn't even prove that they paid for third party software).

In our official report we lambasted the software and highly recommended against purchasing it for any price.

Upper management might as well have used our report for toilet paper, and the reason why is because the deal was already informally made behind closed doors before they even asked us to evaluate what they have committed themselves to.

The bottom line is that while you want to evaulate software on the same principles that you would design and develop new software, just don't be surprised if management will likely ignore your recommendation for political reasons.

+1 a lot of deals are nothing about the technology, they usually want to combine operations or get the customer base. –  james Oct 11 '11 at 14:18

Some parts of CMMI might be useful

You could also run code metric tools for things such as test code coverage, cyclomatic complexity, coupling, and duplication.


Additional process steps, documents to request, and particular questions to ask, can be extracted from both (a) the target (acquired co.) warranties found in disclosed software company merger contracts and (b) the methodologies of repeat acquisitive (e.g., "roll-up") software vendors (e.g., from software merger conferences presos). And some of these points are driven by i.p. and finance / regulatory concerns (at least in the U.S.), including defensive concerns (e.g., what if the deal doesn't happen, you've received confidential info., and the 2 cos. later compete!?). memphishank@aol.com



If the company is looking to "be bought", then they should be providing you the needed documentation. After all, it's their software, and they built it. If they can't provide a complete spec, then your company should probably factor that into the negotiations.

I don't think a company would audit itself: "We're great, everything's perfect, our software is amazing, in fact we recommend a 50% increase". –  Hugo Oct 8 '11 at 5:04
What sort of documentation should I be looking for? So far I've got : Design specs, test plans, network architecture, contracts. I don't think I can do a code review, so perhaps an ERD? –  AvgJoe007 Oct 8 '11 at 7:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.