Most teams have some amount of technical debt. Others are crushed by it. It really shouldn’t be this way. For decades, we’ve been aware of good development practice. We know the things that we should do to avoid incurring technical debt and start paying it back. Clearly, something else is going on.
In this talk, Michael Feathers will explain the root cause of technical debt and the reason why it persists as a problem. There are solutions to the problem but they aren’t in the places we’ve been lead to expect – it is not just a matter of developing better and refactoring more.
Jeroen Moons shares his advice for getting a legacy codebase under control. It’s full of great information, and my favorite quote is on how the code base came to this:
As you poke and prod the area just past the warning sign with a stick, you might wonder: how on earth can anyone have let this happen? Someone must have seen this coming, surely? Were the people who wrote this code that incompetent?
Possibly. But not more so than anyone else. When push comes to shove, however confident people might seem, nobody else knows what they’re doing either.
The whole article is a great read and should be beneficial for when you are tasked with taming the legacy beast.
On his many failed experiments, Thomas Edison once said,
I have learned fifty thousand ways it cannot be done and therefore I am fifty thousand times nearer the final successful experiment.
Elsewhere, we have dug into the data on startups that died (as well as those acquihired) and found they usually die 20 months after raising financing and after having raised about $1.3 million. So we thought it would be useful to see how startup founders and investors describe their failures. While not exactly “50,000 ways it cannot be done,” below is a compilation of startup post-mortems that describe the factors that drove a startup’s demise.
Most of the failures have been told by the company’s founders, but in a few cases, we did find a couple from competitors, early employees, or investors including Roger Ehrenberg (now of IA Ventures) and Bruce Booth (Atlas Venture). They are in no particular order, and there is something to learn from each and every one of them.
Read the entire article at: CB Insights – 156 Startup Failure Post-Mortems
The UNION command is used to select related information from two tables, much like the JOIN command. However, when using the UNION command all selected columns need to be of the same data type. With UNION, only distinct values are selected.
The UNION ALL command is equal to the UNION command, except that UNION ALL selects all values.
The difference between Union and Union all is that Union all will not eliminate duplicate rows, instead, it just pulls all rows from all tables fitting your query specifics and combines them into a table.
A UNION statement effectively does a SELECT DISTINCT on the results set. If you know that all the records returned are unique from your union, use UNION ALL instead, it gives faster results.