38 ms·

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 co

by 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.
- RyanZAG 14y ago
  You (and the author) make a very good point here, and I wasn't disputing that point directly. The issue I was disputing is a generalization made by the author and the people who are insisting on their own 'only way to create software' ideologies. Arguing about software as a whole is flawed, and discussions like this must always be put into context and evidence for or against must be very specific about the exact context. This ties into a similar issue in management academics in which, for decades, people tried to prove a 'best way to manage a company'. Management academics have now moved on from this and all management recommendations are always very rooted in as deep a specific as possible. Software best practices need to make the same transition now. Simply saying 'TDD is best' is the same as saying 'performance linked compensation is best'. Awhile back, a number of idealists very strongly touted the performance linked compensation angle in the same way that a number of software idealists are touting TDD. There is nothing wrong with either idea when used pragmatically and in the correct situations, but the important part for the future and for software as a whole is to discovery the situations in which TDD shines, and the situations it doesn't. Only by breaking it down as specific as possible can we get any real value from TDD recommendations. 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. What I'm trying to get at is that if we can drill down to the specifics we may be able to actually prove things in very specific industries/team structures. We must move away from debating 'software development' as a whole before we can arrive at anything useful though.
rjempson 14y ago
You are right that it was a generalization, however you are pretty much arguing the same point as the author. I remember seeing a matrix/graph in a book, maybe 'code complete' or some other popular book. It basically had complexity on the y axis and risk on the x axis. The point being that high risk, and high complexity projects would justify the most discipline, testing, proofs etc, and the low risk low complexity projects justify minimal process. Something like an inventory management system for a t-shirt shop would be the latter, and sending a pacemaker to the moon would be the former.

by RyanZAG 14y ago

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.

RyanZAG 14y ago
You (and the author) make a very good point here, and I wasn't disputing that point directly. The issue I was disputing is a generalization made by the author and the people who are insisting on their own 'only way to create software' ideologies. Arguing about software as a whole is flawed, and discussions like this must always be put into context and evidence for or against must be very specific about the exact context. This ties into a similar issue in management academics in which, for decades, people tried to prove a 'best way to manage a company'. Management academics have now moved on from this and all management recommendations are always very rooted in as deep a specific as possible. Software best practices need to make the same transition now. Simply saying 'TDD is best' is the same as saying 'performance linked compensation is best'. Awhile back, a number of idealists very strongly touted the performance linked compensation angle in the same way that a number of software idealists are touting TDD. There is nothing wrong with either idea when used pragmatically and in the correct situations, but the important part for the future and for software as a whole is to discovery the situations in which TDD shines, and the situations it doesn't. Only by breaking it down as specific as possible can we get any real value from TDD recommendations. 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. What I'm trying to get at is that if we can drill down to the specifics we may be able to actually prove things in very specific industries/team structures. We must move away from debating 'software development' as a whole before we can arrive at anything useful though.

rjempson 14y ago

You are right that it was a generalization, however you are pretty much arguing the same point as the author. I remember seeing a matrix/graph in a book, maybe 'code complete' or some other popular book. It basically had complexity on the y axis and risk on the x axis. The point being that high risk, and high complexity projects would justify the most discipline, testing, proofs etc, and the low risk low complexity projects justify minimal process. Something like an inventory management system for a t-shirt shop would be the latter, and sending a pacemaker to the moon would be the former.