"We have always done it this way"
As a contractor I get to see how other companies operate, either in documented way or "we have always done this way" (i.e it is stuck in the walls). What I have really learned is that no company is like any other company. But one thing is for sure, having skillful engineers does not always mean that your company will succeed, but it certainly helps.
One scary thing is when everything is "set in the walls" and managers and engineers says "well, we have always done this way", this becomes a answer to whatever question you might have. Very easy to get stuck in this way of doing things.
"You think its wise to always submit patches after 4pm on Friday?" "Well, we have always done that before and it seamed to work out.....", but the company was 3+ years late on their latest project and no stable software in sight. So, NO this was NOT working out.
A example of this was when I and a fellow colleague came into a large company doing embedded software for a multi-mode wireless modem. Before a engineer could deliver his/her updates to the main branch of the software stack each developer should do a "test call". This sounds reasonable and verifies that the developer does not deliver "broken software" to the main branch.
The problem was that getting a test call to be completed could be ten minutes, one hour, one day or even a week, and you would never know if this was because the the "test-network" was down, bad reception, if you had a error in the device driver for the modem or something else had happen. Hence you spend allot of time debugging what was wrong, your board, your software, the drivers, the network, the antenna, etc. etc. And new software deliveries where no-where to be seen.
Making that test call did not prove that you software was correct, the modem had multiple modes, GSM, EDGE, 3G, HSDPA, HSDPA+, LTE (5,10,20 MHz) TDD/FDD and each mode requires their own set of tests. There was off course a large integration testing carried out after you delivered your software to "our" main branch before it was accepted into the main software but that test machinery was very time consuming and a error in our software branch could hinder other updates which was needed by other parts of the project. Complex dependencies existed and new features required that certain patches was included to not hinder other parts of the project.
When we started questioning the test-call was not good enough but would need substantial improved we got the answer "but we have always done it this way". Eventually after working with this issue for about 3+ months we had succeeded in automated everything so that a test-call would become "dependable" and would be a push button solution. This was done at a dedicated test-station which was setup for these kinds of calls and a large amount of scripting was done to automate it. No more fiddling with your modem, your drivers, understanding the test network etc. It would simply work (well, most of the time....).
Constantly question your engineers on how to improve your work flow and if you often get the answer: "We have always done it this way before." then start to question if this is really the best way forward. Constant improvement in your work flow is hard to archive but well worth the effort.