New Role => "Software Inspector"

[Bill Adams]

When I bought my first Car I had my Dad with me.

He made sure I got a good deal, didn't get taken for a ride by unscrupulous salescritters etc.

He made me ask the questions, survey independent research and when the car came - inspect it for defects. He made me literally get under the hood.

Years later when I bought a house I did *my* research but I hired a building inspector I did not know and who did not do a thorough job. Then I learned the hard way.

When software companies gobble up startups do they do they "get under the hood"?

Could an "Software Appraiser" or "Inspector" go into a prospective company  ... "Here's the technical debt you are about to take on. And it will cost you X in terms of Dollars Months Manpower to clean the mess". 

Does such a role exist?

[swkane]

I haven't heard of such a role, and I don't think such a role could exist in the way you describe. Software is not like a house or a car where the individual components have prices and repair costs that can be relatively easily tallied up. Software components are generally wild and wooly beasts that might be similar to other software components, but yet different in other ways that make them difficult or impossible to quantify in terms of 'technical debt' and a price tag to get out of that debt. I personally have not been involved in acquisitions of software companies and so I can't speak from experience, but I suspect the individuals inspecting the company to be acquired look at the 'high level' of the software products that the company offers. They look at features of the software compared to competitors' offerings, and then things like quarterly revenue and overall costs of running the business, not so much the actual code and individual components of the company's software.

Another thing that the car/house analogy fails to account for is the fact that software can generate revenue far beyond the cost to develop it. A house probably won't, and a car almost certainly won't (outside of rare instances of historical significant or collectibility). However, software (even poorly implemented software) can generate significant revenue or have significant potential to generate revenue. If I get an inspection report on a car and it says it is going to cost me $5,000 in repairs to have it running properly, but the car is only worth $1,000, and has so many miles on it that I won't get my money back, I probably won't buy it. Software, on the other hand, is a different beast. I might buy a software company for $10 million, and invest another $50 million in it to get rid of this 'technical debt'. Why? Because it could be an extremely good fit for my multi-billion dollar software company, and it would take me much longer and cost more to get that software otherwise.

Steven

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at https://groups.google.com/group/clean-code-discussion.

[julian higginson]

Yes such a job does exist - a company performing due diligence during the acquisition of another company whose main value is in the software they own, should hire a third party to inspect the codebase... I've been asked to do this before for a company that had a large pile of embedded c code, which is my main thing (though after the purchase was agreed.. oops! and it was pretty bad...) and have a friend who has done it a few times with things relating to security of systems...

It's a consulting role, though the biggest issue is that to do it you need to be trusted by your non-technical business employer to have a good idea of what good and bad code is. And your non technical business employer needs to know that this is even a thing that they can and should do as part of the acquisition process... Also, as far as the reporting goes it can be very hard to estimate the looming cost of fixes, as you obviously don't have time to read and fully understand thousands upon thousands of lines of code - so you basically need to report qualitative opinions.

Now, what happens with the opinions - basically there should already be data on current rate of bugfixes and the current issue backlog, that's understandable at a business level - So the codebase quality informs the new owners how much effort they will need to factor in to driving a new commitment to cleaning it up slowly, over time. And how long they might need to wait before they can start to see an overall faster development time than the previous management had achieved.