4 ms·

> Most of the bullshit (the stuff really slowing you down) that’s in place isn’t there because the business wants it, but because the developers want it. Do yo

> Most of the bullshit (the stuff really slowing you down) that’s in place isn’t there because the business wants it, but because the developers want it. Do you have examples of this? It sounds contrary to my experience.

throwawaymlc 8y ago
I've often seen developers invent elaborate JIRA workflows and pre-checkin validation workflows that slow development to a glacial pace. Also, JIRA / other ticketing workflows can take on a life of their own - at some point, many developers seem to realize that it's easier to describe defects and potential fixes, spend time categorizing, prioritizing, assigning tickets for doing things than it is to ever actually do them.
austincheney 8y ago
Here are some examples: * spaces versus tabs and then rejecting a code commit because of white space or other draconian rules not related to any business justification. * Whether or not a code update performs actions in certain ways, such as specified methods over other methods, without a valid business justification. Normally this appears to be some manner of code style rule. * Rejecting code that uses functions or makes use of lexical scope instead of OOP. * Rejecting code that doesn't make use of the framework even when that particular existing code file doesn't make use of the framework. * Rejecting code that bypasses the framework even though it is a new effort in new files, thus no regression, and has supporting tests. * Rejecting code because the diff is intimidating. * really long build cycles so that a developer can use their favorite framework or tool * A minor tiny module that requires a million dependencies sets off a warning or conflict in your code at build time and requires you to dive under the hood even though the problem is exposed from some horrid dependency. --- If I thought about this more I am sure I could come up with a bunch more. The business never comes to you and mandates you use a popular new JavaScript framework or that the test environment tests for code style and white space. The business doesn't care about this unnecessary stupidity especially if it makes other business requirements, such as security or accessibility, more challenging. The business cares about reducing expenses, retaining users, not getting sued, and generating revenue. You can justify the stupidity with all manner of technical reasons, but in the end does it allow you to perform simple updates in minutes or days? As a developer you are an expense to the business and not a driver of revenue. If you have to justify your limited productivity with a bunch of technical nonsense you are a financial liability.
xkcd-sucks 8y ago
At the company I'm with, there is a 6 person team developing a nodejs app that started out as somebody's learning project / MVP through innumerable pivots (the original developers are gone). The codebase has had no significant deletioms over its five year history, only additions in the "3d chess" sense. It is a generic API server and dropbox-clone file uploader client. It requires on call attention because it blows up every time so etching unexpected happens. Meanwhile, the code that does things the business actually sells is written and maintained by one person, and it works pretty well. There have been several significant rewrites / refactors and little process beyond "the campsite rule" and "get stuff (not shit) done"

throwawaymlc 8y ago

I've often seen developers invent elaborate JIRA workflows and pre-checkin validation workflows that slow development to a glacial pace. Also, JIRA / other ticketing workflows can take on a life of their own - at some point, many developers seem to realize that it's easier to describe defects and potential fixes, spend time categorizing, prioritizing, assigning tickets for doing things than it is to ever actually do them.

austincheney 8y ago

Here are some examples: * spaces versus tabs and then rejecting a code commit because of white space or other draconian rules not related to any business justification. * Whether or not a code update performs actions in certain ways, such as specified methods over other methods, without a valid business justification. Normally this appears to be some manner of code style rule. * Rejecting code that uses functions or makes use of lexical scope instead of OOP. * Rejecting code that doesn't make use of the framework even when that particular existing code file doesn't make use of the framework. * Rejecting code that bypasses the framework even though it is a new effort in new files, thus no regression, and has supporting tests. * Rejecting code because the diff is intimidating. * really long build cycles so that a developer can use their favorite framework or tool * A minor tiny module that requires a million dependencies sets off a warning or conflict in your code at build time and requires you to dive under the hood even though the problem is exposed from some horrid dependency. --- If I thought about this more I am sure I could come up with a bunch more. The business never comes to you and mandates you use a popular new JavaScript framework or that the test environment tests for code style and white space. The business doesn't care about this unnecessary stupidity especially if it makes other business requirements, such as security or accessibility, more challenging. The business cares about reducing expenses, retaining users, not getting sued, and generating revenue. You can justify the stupidity with all manner of technical reasons, but in the end does it allow you to perform simple updates in minutes or days? As a developer you are an expense to the business and not a driver of revenue. If you have to justify your limited productivity with a bunch of technical nonsense you are a financial liability.

xkcd-sucks 8y ago

At the company I'm with, there is a 6 person team developing a nodejs app that started out as somebody's learning project / MVP through innumerable pivots (the original developers are gone). The codebase has had no significant deletioms over its five year history, only additions in the "3d chess" sense. It is a generic API server and dropbox-clone file uploader client. It requires on call attention because it blows up every time so etching unexpected happens. Meanwhile, the code that does things the business actually sells is written and maintained by one person, and it works pretty well. There have been several significant rewrites / refactors and little process beyond "the campsite rule" and "get stuff (not shit) done"