No arguing with that. Same as building material makes a house what it is. The question is, does the success depend on material used? You can build a great house amidst the desert.
But that's an analogy. More real-world example—imagine two startups:
- Startup 1: bad programmer, good QA.
- Startup 2: good programmer, bad QA.
Where would you invest your money?
> If you write bad code, your product may be overbudget, buggy, inadequate, and so on.
Here I disagree. Overbudget? It depends on product success. Buggy? If you have good QA, it's not buggy. Inadequate? You can write the cleanest code, but your product won't work as users want it to.
When we say ‘great product’, do we mean that it has nice clean code, or it's something else? How many great products have bad code?
> There is no dichotomy between the product and the code.
As long as you are ‘just a’ developer, and there are other people focusing on product and its functional quality. In that case you receive specific tasks with deadlines, and yes, you should focus on writing good code.
Not so if you're a solo developer.
1) No one will focus on the product, except you.
2) You most likely would be heavily biased towards writing good code. (Because you're a developer, you're supposed to write good code, right?)
You need to force yourself to focus on the product, to avoid becoming the Startup 2 from above example. Intentionally writing bad code is one way to do that. In that case you at least can be that Startup 1—you'll be forced to pay more attention to functional quality (as opposed to structural), so you'll be good QA.
You can argue that one can focus on both. My opinion is that it's too risky. You need to have priorities set as clear as possible.
> To suggest that you can make better software by neglecting the code is absurd.
Yes, it sounds really controversial (especially to a programmer). I'm far from satisfied with that statement. What would be a better way to be a good QA while being a great programmer?
No arguing with that. Same as building material makes a house what it is. The question is, does the success depend on material used? You can build a great house amidst the desert.
But that's an analogy. More real-world example—imagine two startups:
- Startup 1: bad programmer, good QA. - Startup 2: good programmer, bad QA.
Where would you invest your money?
> If you write bad code, your product may be overbudget, buggy, inadequate, and so on.
Here I disagree. Overbudget? It depends on product success. Buggy? If you have good QA, it's not buggy. Inadequate? You can write the cleanest code, but your product won't work as users want it to.
When we say ‘great product’, do we mean that it has nice clean code, or it's something else? How many great products have bad code?
> There is no dichotomy between the product and the code.
As long as you are ‘just a’ developer, and there are other people focusing on product and its functional quality. In that case you receive specific tasks with deadlines, and yes, you should focus on writing good code.
Not so if you're a solo developer.
1) No one will focus on the product, except you. 2) You most likely would be heavily biased towards writing good code. (Because you're a developer, you're supposed to write good code, right?)
You need to force yourself to focus on the product, to avoid becoming the Startup 2 from above example. Intentionally writing bad code is one way to do that. In that case you at least can be that Startup 1—you'll be forced to pay more attention to functional quality (as opposed to structural), so you'll be good QA.
You can argue that one can focus on both. My opinion is that it's too risky. You need to have priorities set as clear as possible.
> To suggest that you can make better software by neglecting the code is absurd.
Yes, it sounds really controversial (especially to a programmer). I'm far from satisfied with that statement. What would be a better way to be a good QA while being a great programmer?