|
|
|
|
|
|
by wonderwonder
1619 days ago
|
|
|
If I was to guess, I think a lot of it has to do with the transitory nature of so many software jobs coupled with investor pressure to deliver and get ROI. Engineers are switching jobs every couple of years so projects have a constant in stream of new engineers and a constant out stream of tribal knowledge. Very few people are given the proper time to spin up and really learn the codebase, they are given a brief walk through and then expected to start closing tickets. This is how short cuts and not following best habits sneak in. The business side also has immense pressure to start making money so this pressure impacts the software delivery schedule forcing more features into each sprint. Worked at a company where the schedule was always intense but a ton of bugs were making it to production so we decided to introduce unit testing. We all attempted to start learning the new unit testing approach and started on it, but then the pressure from above to deliver features ramped up and the unit tests turned into useless stubs. Couple months later they just ceased to exist. Common response will be to push back and say no but that's not so easy to do in practice when you have to deliver your tickets for the sprint or get pipped. While it may not be so extreme everywhere I bet some aspect of this pressure exists in most places. If not, please let me know where and I will apply :) This is all my anecdotal experience, I could be totally wrong in the grand scheme of things. |
|
|