7 ms·

There is No Right Way to Develop Software

66 points by theli0nheart 14y ago

ankitml 14y ago
wisdom is to know when to apply a theory, knowing when to use a methodology. :) WHen someone says, hiring remote workers is necessary they are talking about it in certain context. Although they might fail to mention that context, or may even fail to notice that underlying context. Not noticing the context doesnt make them fundamentalist, it means that they are not much rigorous or they reached the particular conclusion by trial and error. However to believe in any such conclusion without trying to understand the context or just not being aware to the fact that there might be a context is a folly on your part and not someone who mentioned a particular strategy which worked for them.
yknobel 14y ago
Agree that there's more subjective than objective in best practices. That said, there's nothing wrong with developing and publishing best practices. The fault is in those who turn them into a rigid "bible", rather than food for thought.
FollowSteph3 14y ago
I love "strong opinions weakly held"!! I couldn't agree more.
- pepve 14y ago
  Came here to say the same. Sources for that phrase: http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinions.html http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio... http://www.saffo.com/02008/07/26/strong-opinions-weakly-held/ http://www.saffo.com/02008/07/26/strong-opinions-weakly-held...
bowerbird 14y ago
nope. you're wrong. there _is_ a right way. and furthermore, the best way to write an essay is to organize a meticulous outline in advance. and then _stick_ to it, executing it faithfully. and the best way to take a trip is to _plan_it_, with maps and tourist books, and not waver from the schedule you made, even if (especially if!) you're lured to a bar by someone you wanna boink. stop doing it wrong! -bowerbird
- sturgill 14y ago
  My wife is a planner. I'm more of a "let's get in the car and see where we end up." A healthy mix of both planning and spontaneity adds a lot of variety and enjoyment to life. Which is one reason I love the start-up scene. You start out with a plan, but the challenges come when you have to make important decisions in a moment.
  - bowerbird 14y ago
    i couldn't turn the sarcasm up any more, so i guess i'll just have to turn it off. ;+) -bowerbird
  - bowerbird 14y ago
    i couldn't turn the sarcasm up any more, so i guess i'll just have to turn it off. ;+) -bowerbird
bretthardin 14y ago
My comment without even reading this article: Yes. There is.
lawl 14y ago
I completely agree with the author. I think this can be summarized as "do whatever works best for you". Best practices are great - if they work for you. "Best" is highly subjective in my opinion.
- jspiros 14y ago
  For just a second I considered posting "lol" after reading the comments on this that missed the point, but I realized that's not really appropriate for HN. And besides, I didn't want to make it seem that I don't agree with the author, because I do, completely. Then I realized that you did both for me. So, thanks, lawl.
drdaeman 14y ago
There is no right way, because the term "right" is ambiguous and subjective. Even a ridicuously bug-ridden software can be considered "done right" if the requirements were quick development time and correct results for a single certain case (think of single-use one-liners). However, for example, the only known way to [provably] have a bug-free code is, unsurprisingly, to prove the code is mathematically correct.
- aidenn0 14y ago
  Proving the code is mathematically correct is insufficient. Partial list of bugs I've found before, that (for at least some definitions of "prove") would not be detected by what you suggest. Note that rigorous testing can (and, in fact did) find these. * CPU Bugs (Including one that was unknown to the CPU manufacturer after nearly a decade of deployment) * Memory Bugs * Standard Library Bugs * Compiler Bugs Regehr even gives an example of a proven correct C compiler generating incorrect code (due to an incorrect system header), which was uncovered by testing. [edit] Lest people misunderstand my position, I still think TDD (as it has been explained to me) is BS, but testing, in general, is a necessary part of making reliable software.
  - shared4you 14y ago
    Standard Library and Compiler are also pieces of software, so assuming they could be mathematically proved correct, they won't have bugs either. CPU bug & Memory bugs, yeah, you are right. EDIT: Oh ok, so the system header was not proved mathematically correct :)
deleted 14y ago
[deleted]
qwerta 14y ago
I think the key here is environment. If you are in startup, writing thousand lines per day, then sure tests are not for you. But guy, who takes over code after startup is sold, will have different opinion.
lukeholder 14y ago
I have an interesting experience with this recently. I have been doing ruby now for a few years, I have immersed myself in the culture and concepts. I am wanting to level up on my programming skills, so I am trying to learn Go. I went into a golang irc channel, and was labeled as "ruby brainwashed" because of the way I approached my questions on Go syntax and concepts. I admit I had a hard time mapping object oriented concepts I had come to love in ruby to the different OO model of Go. These guys genuinely thought I was doing things wrong! - it has been a been a wake up call to the many different approaches and opinions.
- SeanDav 14y ago
  Which is why so many top developers recommend that you learn a new language regularly. It exposes you to new thinking and methods. As a result, you grow as a developer. Kudos to you for doing this.
jaggederest 14y ago
Eh, the standard "I don't know which way is best, so there must not be any objectively better or worse ways". There clearly is a correct way to develop software. It's just not clear that we've got enough experience with it to a) have found it, b) to recognize it, and c) to correctly confirm it to a reasonable degree. As I commented on the article, the whole thing sounds a lot more silly if you replace "software development" with "building bridges" or the equivalent civil engineering task. There are clearly better, safer ways to construct bridges, and I'm fairly certain the same is true of software.
- seanmcdirmid 14y ago
  What a load of baloney! There is no one true way to develop software; it depends on the person/team, the nature of the project, the schedule, and tons of other external factors. The same with building bridges actually; to follow the one true way means a lot of bridges falling down. The best we can do is have enough experience and intelligence to choose methods appropriate to the context. That means hiring good developers...because process won't save us!
  - aidenn0 14y ago
    So you're saying choosing methods appropriate to the context and hiring good developers is the one true way to develop software?
    - seanmcdirmid 14y ago
      Ah, that's a good one. Yes, if you want to call that a way.
    - sturgill 14y ago
      Maybe not. Sometimes all you need is developers that are "good enough." I personally don't like hiring junior talent (mostly because I hate all of the hand holding it requires), but that doesn't mean it might not make business sense to go with the cheapest talent that can get the work done. Ironically, if your company uses a lot of junior talent, the appropriate development methods might just require things like enforcing a JIRA ticket before code, always use TDD, etc. Perhaps what I'm saying is the one true way to develop software is to choose your methodologies to maximize the effectiveness of your specific team to fulfill its specific end goal.
lmm 14y ago
No, look, there really are good and bad ways to develop software. If there weren't, no-one would have invented TDD, in fact we'd still be doing everything in FORTRAN. Yes there are disagreements, but we should respond to that by looking deeper and figuring out which parts of each approach are good and which are bad, not throwing up our hands with some relativist "oh, whatever works for you must be the right way, there are no absolute truths".
- seanmcdirmid 14y ago
  > If there weren't, no-one would have invented TDD, in fact we'd still be doing everything in FORTRAN. TDD and FORTRAN are completely orthogonal concepts.... > not throwing up our hands with some relativist "oh, whatever works for you must be the right way, there are no absolute truths". Yep, that's what works in practice. Ideologues don't ship.
  - angersock 14y ago
    > TDD and FORTRAN are completely orthogonal concepts.... False. The testing I've seen heavy Fortran math frameworks go through would probably make the average frontend coder's face melt. Just because it ain't easy doesn't mean it ain't done.
    - seanmcdirmid 14y ago
      You could totally do TDD and FORTRAN together, hence they are orthogonal.
      - angersock 14y ago
        I see where you are going with that, fair enough. I've seen orthogonal used often to denote mutual exclusion instead of independence. My bad. :)
      - cousin_it 14y ago
        Don't mean to disagree with you substantively, but just a note on words: The colloquial meaning of "orthogonal" seems to be "all combinations of these things exist or could exist in theory". That's all good and well, but there's a more faithful way to translate the mathematical concept of orthogonality: "uncorrelated". (Correlation is scaled covariation, which is basically dot product.) Adopting this usage might add some signal to online conversations, e.g. when one hears something like "TDD is orthogonal to Fortran", one could reply "hmm, that's not strictly orthogonal, the real-world correlation seems to be nonzero and negative, which means some real phenomenon must be causing it".
lhnz 14y ago
In fewer words: There exists many context-related local maximas.
RyanZAG 14y ago
The problem here is that these arguments are bulking together many completely different things under the heading of 'software'. This is like trying to find a correct way to 'grow plants'. If you try to grow rice the same way you grow wheat, it's not going to work. This is obvious for plants and should be very obvious for software also. For example, if you're developing a web-based payment processor, you should have unit tests everywhere and possibly additional runtime tests ensuring transactions are completing properly and are stored in the database, etc. If you are developing the software for a pacemaker, unit tests just aren't going to cut it - you will need to logically prove all parts of the software work. You will need to test each piece of hardware to ensure it meets requirements. You will need to do hundreds of hours of physical testing to ensure everything works in different environments and with different electromagnetic interference. Just doing a bit of TDD is laughable here. Lean startup validating an idea? History shows that simply shipping and having something that users can try to use is more than enough. If it breaks and goes down for hours? No problem - customers will sit there hitting F5 for hours for the chance to use it again. If nobody wants to use it, your tests are wasted anyway. In this environment, having something that partially works is better than something that isn't done yet. There are millions of other cases, each of them unique. Software development is not building bridges. Please never use that analogy - a bridge is a fixed, known, and obvious requirement and solution. Software is the very opposite of this - if you compare 'software' to the combined industries of fabrics, farming, engineering, carpentry, electrical work, industrial building, home building and many more, then your analogy is closer to the truth.
- zzzcpan 14y ago
  No, there is no problem with the argument. It applies to every special case of software. For example, you may think that your ideas to develop good software in payment processor are right, but they aren't really right. You have no evidence that such way of developing this particular type of software leads to more reliability and security than every other way. Same goes for every other example you mentioned. So, if you cannot prove that it's right or better, why do you say that it is? I think this is the point of the article.
  - 14y ago
annymsMthd 14y ago
It all boils down to maintainability. Do I want to even attempt debugging or adding features to a 10,000 + line ASP.NET Web form page? What about a MVC project where someone took the time to observe separation of concerns and wrote unit tests for everything? Automated tests of any sort will save you when the code base grows, and it will. There are different code smells for different languages and platforms but the real developers will smell them out and see them for what they are, the wrong way to write software. Bad code is bad code and it is always the wrong way.
michaelochurch 14y ago
I asked an experienced Bridge player about bidding conventions, and if there was one right way to bid a hand. He said, "there isn't one right way to bid, but there are plenty of wrong ways." That's how I feel about software development (and business operations in general). Is there an inflexible, one-size-fit-all, "right" methodology? Hell no. Even open allocation (which isn't really a methodology) isn't right for every company out there. There are, however, a ton of wrong ways to do things. The sad thing is that, because most people are driven by a mix of ego and incompetence, wrong ways of doing things are the most common. You're Doing It Wrong if: * managers have more power than engineers. * mutually positive contributions (good for engineer and for firm) are disallowed for political reasons. * people can't get shit done because of too much pointless process (to start writing code, you need a Jira ticket). * stand-up takes 45 minutes and people sit down. * people are micromanaged and start doing things badly, or overmonitored (the hidden danger of too much Jira activity) and start panic-coding. * designs are made by incompetents. * ... and many, many more.
- scott_w 14y ago
  Interestingly, you did exactly what the author warned against, but replaced "right" with "wrong". Some things are obvious (designs made by incompetent designers), but then giving the example of "No code without a Jira ticket" is almost certainly your personal pet peeve.
  - michaelochurch 14y ago
    My point is that "no code without a Jira ticket" is a bad process. Slapping reporting overhead on small code changes is ridiculous. Maybe I didn't make that clear. I don't support that. I have a lot of pet peeves, because I've seen so much done wrong. Competent software managers are extremely uncommon. Maybe 1 in 20. In the '90s, people who studied day traders found that they were reliably making money on their core strategies, but those were generally only available for a small amount of time, and that most of them lost their shirts through "boredom trading" outside of their core competence that had zero-to-negative expectancy and only added noise. Boredom trading occurs because ego, combined with a need to feel active, results in a lot of activity that cuts away at the profits earned during one's good hour or two per day. Managers are a case of trader boredom. They'd actually be quite effective if they scaled back to 1/10 the amount of process and interference, but their trader boredom just causes them to throw everything out of whack. If managers were socially permitted to work 5-10 hours per week instead of being expected to fill time by bothering people, they'd probably do a much better job.
jt2190 14y ago
Novices generally don't have enough experience to distinguish between situations that require a "best" practice and those that don't, hence advice given to novices is generally phrased in absolute terms: "Never...", "always...", etc. Experienced programmers have used the "best" practices enough that they know their limitations, and so they pick and choose accordingly. pragdave gave a great talk on this very subject a few years ago: http://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas http://www.infoq.com/presentations/Developing-Expertise-Dave...
Stranger2013 14y ago
These kind of posts are a natural response to all the TDD hype.
greensand 14y ago
ah, the sweet voice of sanity
mwcampbell 14y ago
This reminds me of the politically correct, relativist nonsense that one often sees in response to the existence of multiple, mutually exclusive religions. There may not be a single right way to develop all software, but as with questions of morality, there are certainly better or worse ways, and in principle, we can find them through science. Hopefully we can at least come to some definitive conclusions about "worst practices", if not best practices.
- zzzcpan 14y ago
  The problem is that these better ways are mostly based on opinions of others and usually lack any real evidence.
Zigurd 14y ago
The truest statement I have read in these comments so far is that we don't yet know the best way or ways to do software development. There might be one or more best ways, but we don't know. The article is valuable in pointing out that most purported "best ways" are dogmas, and, despite claims of being scientific, they tend to veer off into pseudoscience. And yet, if you don't have a plan, if you don't apply the best available tools, and if you don't have expertise and experience, you're going to have a bad time. That leaves software development as something less than engineering, and more like a craft. You can't make it happen, or manage it, without expertise, creativity, and intellect. Attempts to stuff it into a contained, measurable space almost always result in perverse incentives and efficiency comparable to a Soviet 5 year plan. But that doesn't mean that a best way doesn't exist, or that it will never be found.

66 points by theli0nheart 14y ago

wisdom is to know when to apply a theory, knowing when to use a methodology. :) WHen someone says, hiring remote workers is necessary they are talking about it in certain context. Although they might fail to mention that context, or may even fail to notice that underlying context. Not noticing the context doesnt make them fundamentalist, it means that they are not much rigorous or they reached the particular conclusion by trial and error. However to believe in any such conclusion without trying to understand the context or just not being aware to the fact that there might be a context is a folly on your part and not someone who mentioned a particular strategy which worked for them.

yknobel 14y ago

Agree that there's more subjective than objective in best practices. That said, there's nothing wrong with developing and publishing best practices. The fault is in those who turn them into a rigid "bible", rather than food for thought.

FollowSteph3 14y ago

I love "strong opinions weakly held"!! I couldn't agree more.

pepve 14y ago
Came here to say the same. Sources for that phrase: http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinions.html http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio... http://www.saffo.com/02008/07/26/strong-opinions-weakly-held/ http://www.saffo.com/02008/07/26/strong-opinions-weakly-held...

bowerbird 14y ago

nope. you're wrong. there _is_ a right way. and furthermore, the best way to write an essay is to organize a meticulous outline in advance. and then _stick_ to it, executing it faithfully. and the best way to take a trip is to _plan_it_, with maps and tourist books, and not waver from the schedule you made, even if (especially if!) you're lured to a bar by someone you wanna boink. stop doing it wrong! -bowerbird

sturgill 14y ago
My wife is a planner. I'm more of a "let's get in the car and see where we end up." A healthy mix of both planning and spontaneity adds a lot of variety and enjoyment to life. Which is one reason I love the start-up scene. You start out with a plan, but the challenges come when you have to make important decisions in a moment.
- bowerbird 14y ago
  i couldn't turn the sarcasm up any more, so i guess i'll just have to turn it off. ;+) -bowerbird
- bowerbird 14y ago
  i couldn't turn the sarcasm up any more, so i guess i'll just have to turn it off. ;+) -bowerbird

bretthardin 14y ago

My comment without even reading this article: Yes. There is.

lawl 14y ago

I completely agree with the author. I think this can be summarized as "do whatever works best for you". Best practices are great - if they work for you. "Best" is highly subjective in my opinion.

jspiros 14y ago
For just a second I considered posting "lol" after reading the comments on this that missed the point, but I realized that's not really appropriate for HN. And besides, I didn't want to make it seem that I don't agree with the author, because I do, completely. Then I realized that you did both for me. So, thanks, lawl.

drdaeman 14y ago

There is no right way, because the term "right" is ambiguous and subjective. Even a ridicuously bug-ridden software can be considered "done right" if the requirements were quick development time and correct results for a single certain case (think of single-use one-liners). However, for example, the only known way to [provably] have a bug-free code is, unsurprisingly, to prove the code is mathematically correct.

aidenn0 14y ago
Proving the code is mathematically correct is insufficient. Partial list of bugs I've found before, that (for at least some definitions of "prove") would not be detected by what you suggest. Note that rigorous testing can (and, in fact did) find these. * CPU Bugs (Including one that was unknown to the CPU manufacturer after nearly a decade of deployment) * Memory Bugs * Standard Library Bugs * Compiler Bugs Regehr even gives an example of a proven correct C compiler generating incorrect code (due to an incorrect system header), which was uncovered by testing. [edit] Lest people misunderstand my position, I still think TDD (as it has been explained to me) is BS, but testing, in general, is a necessary part of making reliable software.
- shared4you 14y ago
  Standard Library and Compiler are also pieces of software, so assuming they could be mathematically proved correct, they won't have bugs either. CPU bug & Memory bugs, yeah, you are right. EDIT: Oh ok, so the system header was not proved mathematically correct :)

deleted 14y ago

[deleted]

qwerta 14y ago

I think the key here is environment. If you are in startup, writing thousand lines per day, then sure tests are not for you. But guy, who takes over code after startup is sold, will have different opinion.

lukeholder 14y ago

I have an interesting experience with this recently. I have been doing ruby now for a few years, I have immersed myself in the culture and concepts. I am wanting to level up on my programming skills, so I am trying to learn Go. I went into a golang irc channel, and was labeled as "ruby brainwashed" because of the way I approached my questions on Go syntax and concepts. I admit I had a hard time mapping object oriented concepts I had come to love in ruby to the different OO model of Go. These guys genuinely thought I was doing things wrong! - it has been a been a wake up call to the many different approaches and opinions.

SeanDav 14y ago
Which is why so many top developers recommend that you learn a new language regularly. It exposes you to new thinking and methods. As a result, you grow as a developer. Kudos to you for doing this.

jaggederest 14y ago

Eh, the standard "I don't know which way is best, so there must not be any objectively better or worse ways". There clearly is a correct way to develop software. It's just not clear that we've got enough experience with it to a) have found it, b) to recognize it, and c) to correctly confirm it to a reasonable degree. As I commented on the article, the whole thing sounds a lot more silly if you replace "software development" with "building bridges" or the equivalent civil engineering task. There are clearly better, safer ways to construct bridges, and I'm fairly certain the same is true of software.

seanmcdirmid 14y ago
What a load of baloney! There is no one true way to develop software; it depends on the person/team, the nature of the project, the schedule, and tons of other external factors. The same with building bridges actually; to follow the one true way means a lot of bridges falling down. The best we can do is have enough experience and intelligence to choose methods appropriate to the context. That means hiring good developers...because process won't save us!
- aidenn0 14y ago
  So you're saying choosing methods appropriate to the context and hiring good developers is the one true way to develop software?
  - seanmcdirmid 14y ago
    Ah, that's a good one. Yes, if you want to call that a way.
  - sturgill 14y ago
    Maybe not. Sometimes all you need is developers that are "good enough." I personally don't like hiring junior talent (mostly because I hate all of the hand holding it requires), but that doesn't mean it might not make business sense to go with the cheapest talent that can get the work done. Ironically, if your company uses a lot of junior talent, the appropriate development methods might just require things like enforcing a JIRA ticket before code, always use TDD, etc. Perhaps what I'm saying is the one true way to develop software is to choose your methodologies to maximize the effectiveness of your specific team to fulfill its specific end goal.

lmm 14y ago

No, look, there really are good and bad ways to develop software. If there weren't, no-one would have invented TDD, in fact we'd still be doing everything in FORTRAN. Yes there are disagreements, but we should respond to that by looking deeper and figuring out which parts of each approach are good and which are bad, not throwing up our hands with some relativist "oh, whatever works for you must be the right way, there are no absolute truths".

seanmcdirmid 14y ago
> If there weren't, no-one would have invented TDD, in fact we'd still be doing everything in FORTRAN. TDD and FORTRAN are completely orthogonal concepts.... > not throwing up our hands with some relativist "oh, whatever works for you must be the right way, there are no absolute truths". Yep, that's what works in practice. Ideologues don't ship.
- angersock 14y ago
  > TDD and FORTRAN are completely orthogonal concepts.... False. The testing I've seen heavy Fortran math frameworks go through would probably make the average frontend coder's face melt. Just because it ain't easy doesn't mean it ain't done.
  - seanmcdirmid 14y ago
    You could totally do TDD and FORTRAN together, hence they are orthogonal.
    - angersock 14y ago
      I see where you are going with that, fair enough. I've seen orthogonal used often to denote mutual exclusion instead of independence. My bad. :)
    - cousin_it 14y ago
      Don't mean to disagree with you substantively, but just a note on words: The colloquial meaning of "orthogonal" seems to be "all combinations of these things exist or could exist in theory". That's all good and well, but there's a more faithful way to translate the mathematical concept of orthogonality: "uncorrelated". (Correlation is scaled covariation, which is basically dot product.) Adopting this usage might add some signal to online conversations, e.g. when one hears something like "TDD is orthogonal to Fortran", one could reply "hmm, that's not strictly orthogonal, the real-world correlation seems to be nonzero and negative, which means some real phenomenon must be causing it".

lhnz 14y ago

In fewer words: There exists many context-related local maximas.

RyanZAG 14y ago

The problem here is that these arguments are bulking together many completely different things under the heading of 'software'. This is like trying to find a correct way to 'grow plants'. If you try to grow rice the same way you grow wheat, it's not going to work. This is obvious for plants and should be very obvious for software also. For example, if you're developing a web-based payment processor, you should have unit tests everywhere and possibly additional runtime tests ensuring transactions are completing properly and are stored in the database, etc. If you are developing the software for a pacemaker, unit tests just aren't going to cut it - you will need to logically prove all parts of the software work. You will need to test each piece of hardware to ensure it meets requirements. You will need to do hundreds of hours of physical testing to ensure everything works in different environments and with different electromagnetic interference. Just doing a bit of TDD is laughable here. Lean startup validating an idea? History shows that simply shipping and having something that users can try to use is more than enough. If it breaks and goes down for hours? No problem - customers will sit there hitting F5 for hours for the chance to use it again. If nobody wants to use it, your tests are wasted anyway. In this environment, having something that partially works is better than something that isn't done yet. There are millions of other cases, each of them unique. Software development is not building bridges. Please never use that analogy - a bridge is a fixed, known, and obvious requirement and solution. Software is the very opposite of this - if you compare 'software' to the combined industries of fabrics, farming, engineering, carpentry, electrical work, industrial building, home building and many more, then your analogy is closer to the truth.

zzzcpan 14y ago
No, there is no problem with the argument. It applies to every special case of software. For example, you may think that your ideas to develop good software in payment processor are right, but they aren't really right. You have no evidence that such way of developing this particular type of software leads to more reliability and security than every other way. Same goes for every other example you mentioned. So, if you cannot prove that it's right or better, why do you say that it is? I think this is the point of the article.
- 14y ago

annymsMthd 14y ago

It all boils down to maintainability. Do I want to even attempt debugging or adding features to a 10,000 + line ASP.NET Web form page? What about a MVC project where someone took the time to observe separation of concerns and wrote unit tests for everything? Automated tests of any sort will save you when the code base grows, and it will. There are different code smells for different languages and platforms but the real developers will smell them out and see them for what they are, the wrong way to write software. Bad code is bad code and it is always the wrong way.

michaelochurch 14y ago

I asked an experienced Bridge player about bidding conventions, and if there was one right way to bid a hand. He said, "there isn't one right way to bid, but there are plenty of wrong ways." That's how I feel about software development (and business operations in general). Is there an inflexible, one-size-fit-all, "right" methodology? Hell no. Even open allocation (which isn't really a methodology) isn't right for every company out there. There are, however, a ton of wrong ways to do things. The sad thing is that, because most people are driven by a mix of ego and incompetence, wrong ways of doing things are the most common. You're Doing It Wrong if: * managers have more power than engineers. * mutually positive contributions (good for engineer and for firm) are disallowed for political reasons. * people can't get shit done because of too much pointless process (to start writing code, you need a Jira ticket). * stand-up takes 45 minutes and people sit down. * people are micromanaged and start doing things badly, or overmonitored (the hidden danger of too much Jira activity) and start panic-coding. * designs are made by incompetents. * ... and many, many more.

scott_w 14y ago
Interestingly, you did exactly what the author warned against, but replaced "right" with "wrong". Some things are obvious (designs made by incompetent designers), but then giving the example of "No code without a Jira ticket" is almost certainly your personal pet peeve.
- michaelochurch 14y ago
  My point is that "no code without a Jira ticket" is a bad process. Slapping reporting overhead on small code changes is ridiculous. Maybe I didn't make that clear. I don't support that. I have a lot of pet peeves, because I've seen so much done wrong. Competent software managers are extremely uncommon. Maybe 1 in 20. In the '90s, people who studied day traders found that they were reliably making money on their core strategies, but those were generally only available for a small amount of time, and that most of them lost their shirts through "boredom trading" outside of their core competence that had zero-to-negative expectancy and only added noise. Boredom trading occurs because ego, combined with a need to feel active, results in a lot of activity that cuts away at the profits earned during one's good hour or two per day. Managers are a case of trader boredom. They'd actually be quite effective if they scaled back to 1/10 the amount of process and interference, but their trader boredom just causes them to throw everything out of whack. If managers were socially permitted to work 5-10 hours per week instead of being expected to fill time by bothering people, they'd probably do a much better job.

jt2190 14y ago

Novices generally don't have enough experience to distinguish between situations that require a "best" practice and those that don't, hence advice given to novices is generally phrased in absolute terms: "Never...", "always...", etc. Experienced programmers have used the "best" practices enough that they know their limitations, and so they pick and choose accordingly. pragdave gave a great talk on this very subject a few years ago: http://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas http://www.infoq.com/presentations/Developing-Expertise-Dave...

Stranger2013 14y ago

These kind of posts are a natural response to all the TDD hype.

greensand 14y ago

ah, the sweet voice of sanity

mwcampbell 14y ago

This reminds me of the politically correct, relativist nonsense that one often sees in response to the existence of multiple, mutually exclusive religions. There may not be a single right way to develop all software, but as with questions of morality, there are certainly better or worse ways, and in principle, we can find them through science. Hopefully we can at least come to some definitive conclusions about "worst practices", if not best practices.

zzzcpan 14y ago
The problem is that these better ways are mostly based on opinions of others and usually lack any real evidence.

Zigurd 14y ago

The truest statement I have read in these comments so far is that we don't yet know the best way or ways to do software development. There might be one or more best ways, but we don't know. The article is valuable in pointing out that most purported "best ways" are dogmas, and, despite claims of being scientific, they tend to veer off into pseudoscience. And yet, if you don't have a plan, if you don't apply the best available tools, and if you don't have expertise and experience, you're going to have a bad time. That leaves software development as something less than engineering, and more like a craft. You can't make it happen, or manage it, without expertise, creativity, and intellect. Attempts to stuff it into a contained, measurable space almost always result in perverse incentives and efficiency comparable to a Soviet 5 year plan. But that doesn't mean that a best way doesn't exist, or that it will never be found.