5 ms·

As someone who works at a place that has tons of technical debt yet is able to release daily, I have to disagree. We have things that are 6+ months old without

As someone who works at a place that has tons of technical debt yet is able to release daily, I have to disagree. We have things that are 6+ months old without any of the normal best practices and are able to continue to ship w/o delay. Hell, for a new project/service two of my coworkers completely bypassed version control and unit tests. You can achieve high velocity without high quality. The cost to do that is sometimes you have an expensive production bug to fix. Please note, I'm not endorsing the way my coworkers do things but I've given up fighting any of it outside of my narrow slice of turf. ;)

vinceguidry 12y ago
This is a giant mess waiting to happen. Eventually the pace of development will slow to a crawl as incoherence of the technical decisions made build up. Then when the developers leave, forcing the next guy to work to understand now-legacy projects, all of a sudden the velocity the company has heretofore enjoyed will be gone.
- opendais 12y ago
  It has been this way for 10 years and predates me working there. The pace of development remains unchanged as far as I can tell over the time I've worked there, regardless of whom left and was hired. I was pointing this out not to say it was a good thing but rather that the premise of [Quality == Speed] is flawed.
sheepmullet 12y ago
It sounds like releasing daily is part of your testing strategy in that you simply let your customers do the testing for you. Making small incremental changes with extensive manual testing can work. It just looks like you don't have to pay for the test effort. I've seen it a fair bit with internal projects at larger companies but most external customers I have met in my career would quickly switch products. Edit: It also sounds like you are confusing best practices with good code. I've met teams, usually without a formal cs education, who haven't used version control and didn't have any unit tests, but still had a well designed codebase. Of course best practices are best practices for a reason....
- opendais 12y ago
  Hahahahahahaha. If only. <3 Its an ecommerce site. So its all external customers [including API integrations with external IT departments]. I'm amazed we get away with it tbh.
- opendais 12y ago
  > Edit: It also sounds like you are confusing best practices with good code. I've met teams, usually without a formal cs education, who haven't used version control and didn't have any unit tests, but still had a well designed codebase. Of course best practices are best practices for a reason.... 1) They both have degrees in comp sci. 2) For very narrow definitions of the word "good" you would be correct. Its technically functional and reliable. However, it regularly has problems with security and/or changes to the common library breaking other people's services.
robalfonso 12y ago
Question: What is on-boarding new employees like with that system? How long does it take you to get people up to speed and being productive? I would suppose the lack of rules makes them fast in the beginning and in the end they are contributing to the mess in their own special way, doubling down on the technical debt.
- opendais 12y ago
  I can't really answer that question completely accurately. I was a very odd case/hire compared to those both before and after as far as I can tell. I mostly interface with outside developers for integration purposes and I never really had a normal on boarding process. I'm just a random developer with no authority/power. That said, my best guess is: > 1) What is on-boarding new employees like with that system? They get an intranet project that is relatively harmless and helps them learn the common library -> they get assigned projects on the main site and get progressively larger features to implement. There is no real documentation beyond the actual codebase and asking people questions. > 2) How long does it take you to get people up to speed and being productive? No clue. I'd guess 2 months based on how quickly I switched from "intranet projects" to integrating Amazon MWS, 3rd parties, etc. > 3) I would suppose the lack of rules makes them fast in the beginning and in the end they are contributing to the mess in their own special way, doubling down on the technical debt. More or less, yes. An example would be we now have 3 partial versions of the same intranet application. The super old one, the one I built before handing it off to the new guy, and the new guy's version [because he didn't like my version].
ScottBurson 12y ago
The critical thing is that the architecture remain coherent. Modules have to have clear responsibilities and not get cluttered with special-case hacks that really belong somewhere else. If you keep things reasonably clean that way, I think you can survive being sloppy about other recommended practices... barely, and with effort, but you can survive. But if no one can understand how the system works and predict the effects of changes, the thing is doomed.
- opendais 12y ago
  Yes. I wouldn't say doomed tho. It just leads to production bugs that are costly.

vinceguidry 12y ago

This is a giant mess waiting to happen. Eventually the pace of development will slow to a crawl as incoherence of the technical decisions made build up. Then when the developers leave, forcing the next guy to work to understand now-legacy projects, all of a sudden the velocity the company has heretofore enjoyed will be gone.

opendais 12y ago
It has been this way for 10 years and predates me working there. The pace of development remains unchanged as far as I can tell over the time I've worked there, regardless of whom left and was hired. I was pointing this out not to say it was a good thing but rather that the premise of [Quality == Speed] is flawed.

sheepmullet 12y ago

It sounds like releasing daily is part of your testing strategy in that you simply let your customers do the testing for you. Making small incremental changes with extensive manual testing can work. It just looks like you don't have to pay for the test effort. I've seen it a fair bit with internal projects at larger companies but most external customers I have met in my career would quickly switch products. Edit: It also sounds like you are confusing best practices with good code. I've met teams, usually without a formal cs education, who haven't used version control and didn't have any unit tests, but still had a well designed codebase. Of course best practices are best practices for a reason....

opendais 12y ago
Hahahahahahaha. If only. <3 Its an ecommerce site. So its all external customers [including API integrations with external IT departments]. I'm amazed we get away with it tbh.
opendais 12y ago
> Edit: It also sounds like you are confusing best practices with good code. I've met teams, usually without a formal cs education, who haven't used version control and didn't have any unit tests, but still had a well designed codebase. Of course best practices are best practices for a reason.... 1) They both have degrees in comp sci. 2) For very narrow definitions of the word "good" you would be correct. Its technically functional and reliable. However, it regularly has problems with security and/or changes to the common library breaking other people's services.

robalfonso 12y ago

Question: What is on-boarding new employees like with that system? How long does it take you to get people up to speed and being productive? I would suppose the lack of rules makes them fast in the beginning and in the end they are contributing to the mess in their own special way, doubling down on the technical debt.

opendais 12y ago
I can't really answer that question completely accurately. I was a very odd case/hire compared to those both before and after as far as I can tell. I mostly interface with outside developers for integration purposes and I never really had a normal on boarding process. I'm just a random developer with no authority/power. That said, my best guess is: > 1) What is on-boarding new employees like with that system? They get an intranet project that is relatively harmless and helps them learn the common library -> they get assigned projects on the main site and get progressively larger features to implement. There is no real documentation beyond the actual codebase and asking people questions. > 2) How long does it take you to get people up to speed and being productive? No clue. I'd guess 2 months based on how quickly I switched from "intranet projects" to integrating Amazon MWS, 3rd parties, etc. > 3) I would suppose the lack of rules makes them fast in the beginning and in the end they are contributing to the mess in their own special way, doubling down on the technical debt. More or less, yes. An example would be we now have 3 partial versions of the same intranet application. The super old one, the one I built before handing it off to the new guy, and the new guy's version [because he didn't like my version].

ScottBurson 12y ago

The critical thing is that the architecture remain coherent. Modules have to have clear responsibilities and not get cluttered with special-case hacks that really belong somewhere else. If you keep things reasonably clean that way, I think you can survive being sloppy about other recommended practices... barely, and with effort, but you can survive. But if no one can understand how the system works and predict the effects of changes, the thing is doomed.

opendais 12y ago
Yes. I wouldn't say doomed tho. It just leads to production bugs that are costly.