6 ms·

> Product managers/sales/marketing do not care about your unit tests Only if they have no technical understanding of it. Once they understand how these prevent

> Product managers/sales/marketing do not care about your unit tests Only if they have no technical understanding of it. Once they understand how these prevent regressions and provide confidence that stuff works as expected, they start to value it. It's our job as developers to explain the importance of unit tests, and why they're non-negotiable. Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do).

talmand 9y ago
>> non-negotiable Sure.
knightofmars 9y ago
Yes. This is the difference in perspective between a company founded by a technical person (or someone who has a competent technical "right hand") and one founded by a non technical person. A company can succeed for many years, 10+, with a non technical person. At some point the decisions made and the shortcuts will start to catch up. Having worked on legacy code bases with version control you start to see patterns. While there are definitely those decisions made because they were required at the time there are also definitely those individuals who obviously were out of their depth or were willing to "hack it" to get it to work. And a lot of times, they are lauded as being "A+ top producers" when the reality was they just did it faster than everyone else because they didn't think about long-term quality. The story version, I see in terms of manufacturing. If I was working with a parts supplier and asked for them to deliver a part I needed. The requirement was as fast as they could do it. They make good on the delivery. From a business perspective everything is great. We're making sales and we met our deadlines. The supplier was great in helping us out. Suddenly three years into our five year warranty parts from the supplier start failing (performance problems and fragile releases). It becomes obvious there's a major quality problem in the parts that were manufactured. We talk to the parts supplier but they've gone insolvent (the software engineer left the company). Suddenly we need to hire a new parts supplier (a new software engineer with years of experience) to rush the replacement parts that are required to meet our warranty. Which, (hopefully) having learned our lesson are paying the higher rate (proper compensation and reasonable time for quality) to guarantee a quality replacement part to prevent the loss of profits of another round of extended warranty replacements. At this point the company has just cost itself both monetarily and potentially in reputation by making the original decision to fast-track production to "get to market". I recognize that the scenario above isn't software. It's a physical thing that's gone out into the world out of the control of the company that created it. But fundamentally the same trade-off of "deliver it now" vs "deliver it right" is made. And often made by people who don't never consider the long-term costs (technical debt) because "that's not now, that's in the future". And people will often rationalize their decisions in these situations. The often spoken: Over confidence "That happens to other companies, we'll be successful." Lack of understanding "I don't care about the outcome, we need it now." Individual worship "John said we could do it, so we're doing it." Punting "We'll deal with it once we have slack time."
notyourday 9y ago
> It's our job as developers to explain the importance of unit tests, and why they're non-negotiable. Let me put on a hat that I wore a few times - someone who had one person above him in a company. I will also preface this with 'I hate sloppy code. I hate shortcuts. I want people to spend time on building tooling instead of writing features. If I could wave a magic wand we would have 99% test coverage'. This is 100% incorrect. Code quality on a list of priorities for the business is somewhere between the taste of a three day old coffee and a french fry that fell off a tray. Business is there to make money. It means that code that works somehow is better than perfect code which did not happen to ship because developers are still working on the unit tests. Developer time costs money. Operations people time costs money. Anything that does not make money but costs money gets de-prioritized. If you think that "code smell" and "unit tests" are non-negotiable especially if it is at the cost of tweaking/fixing something that is going to generate revenue, you are drawing a line in a sand and I'm going to have to point you at the door. If you would like to get me to allocate resources ( read: $$ ) to address code smell/code stench/etc, you need to either convince me that the sky is falling ( i.e. we start losing money/we are going to start losing customers ) or you need to give me something that can offset some of my costs or you need to come up with a clever way to enable us to make more money. > Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do). Exactly. The "right time" may not be now and may not be before. It may also not been for another year. P.S. Incidentally, this is also why product people/project managers and sales people get a better seat at the table than developers ( which is a mistake, from my perspective ) - they typically talk about money while developers talk about code.
- Retra 9y ago
  But now you're asking software people to predict long term costs on processes they don't even control, and it's already notoriously impossible for them to do it in the short term on processes they do. I don't see how you can expect more than "if we don't do it, we'll eventually have problems." Customers might leave and features will get harder to implement. It all costs money, but how much is very difficult to say.
  - notyourday 9y ago

talmand 9y ago

>> non-negotiable Sure.

knightofmars 9y ago

Yes. This is the difference in perspective between a company founded by a technical person (or someone who has a competent technical "right hand") and one founded by a non technical person. A company can succeed for many years, 10+, with a non technical person. At some point the decisions made and the shortcuts will start to catch up. Having worked on legacy code bases with version control you start to see patterns. While there are definitely those decisions made because they were required at the time there are also definitely those individuals who obviously were out of their depth or were willing to "hack it" to get it to work. And a lot of times, they are lauded as being "A+ top producers" when the reality was they just did it faster than everyone else because they didn't think about long-term quality. The story version, I see in terms of manufacturing. If I was working with a parts supplier and asked for them to deliver a part I needed. The requirement was as fast as they could do it. They make good on the delivery. From a business perspective everything is great. We're making sales and we met our deadlines. The supplier was great in helping us out. Suddenly three years into our five year warranty parts from the supplier start failing (performance problems and fragile releases). It becomes obvious there's a major quality problem in the parts that were manufactured. We talk to the parts supplier but they've gone insolvent (the software engineer left the company). Suddenly we need to hire a new parts supplier (a new software engineer with years of experience) to rush the replacement parts that are required to meet our warranty. Which, (hopefully) having learned our lesson are paying the higher rate (proper compensation and reasonable time for quality) to guarantee a quality replacement part to prevent the loss of profits of another round of extended warranty replacements. At this point the company has just cost itself both monetarily and potentially in reputation by making the original decision to fast-track production to "get to market". I recognize that the scenario above isn't software. It's a physical thing that's gone out into the world out of the control of the company that created it. But fundamentally the same trade-off of "deliver it now" vs "deliver it right" is made. And often made by people who don't never consider the long-term costs (technical debt) because "that's not now, that's in the future". And people will often rationalize their decisions in these situations. The often spoken: Over confidence "That happens to other companies, we'll be successful." Lack of understanding "I don't care about the outcome, we need it now." Individual worship "John said we could do it, so we're doing it." Punting "We'll deal with it once we have slack time."

notyourday 9y ago

> It's our job as developers to explain the importance of unit tests, and why they're non-negotiable. Let me put on a hat that I wore a few times - someone who had one person above him in a company. I will also preface this with 'I hate sloppy code. I hate shortcuts. I want people to spend time on building tooling instead of writing features. If I could wave a magic wand we would have 99% test coverage'. This is 100% incorrect. Code quality on a list of priorities for the business is somewhere between the taste of a three day old coffee and a french fry that fell off a tray. Business is there to make money. It means that code that works somehow is better than perfect code which did not happen to ship because developers are still working on the unit tests. Developer time costs money. Operations people time costs money. Anything that does not make money but costs money gets de-prioritized. If you think that "code smell" and "unit tests" are non-negotiable especially if it is at the cost of tweaking/fixing something that is going to generate revenue, you are drawing a line in a sand and I'm going to have to point you at the door. If you would like to get me to allocate resources ( read: $$ ) to address code smell/code stench/etc, you need to either convince me that the sky is falling ( i.e. we start losing money/we are going to start losing customers ) or you need to give me something that can offset some of my costs or you need to come up with a clever way to enable us to make more money. > Also, if you do the tests at the right time, you end up saving time. I've learnt that the hard way (as most do). Exactly. The "right time" may not be now and may not be before. It may also not been for another year. P.S. Incidentally, this is also why product people/project managers and sales people get a better seat at the table than developers ( which is a mistake, from my perspective ) - they typically talk about money while developers talk about code.

Retra 9y ago
But now you're asking software people to predict long term costs on processes they don't even control, and it's already notoriously impossible for them to do it in the short term on processes they do. I don't see how you can expect more than "if we don't do it, we'll eventually have problems." Customers might leave and features will get harder to implement. It all costs money, but how much is very difficult to say.
- notyourday 9y ago