4 ms·

Yes, do everything all at once. And never be able to release anything.

by btym 10y ago

YZF 10y ago
That's not what I said. Do what needs to be done at a given point in time to release. Just don't soothe your conscience by putting a TODO in the code. 99% that TODO will never get done, it's just clutter and code smell. If your code is broken you're releasing something that's broken which is probably going to end badly. If the code is adequate then it's adequate. Often it's just perception that doing it wrong is faster than doing it right. Prefer doing it right. (EDIT- doing it right is often faster)
- bArray 10y ago
  I'm not sure this model works, in at least my case. Where there is perhaps some circuit you need to validate actually works with some sort of code - it's often useful to write some bad display driver for example so that the hardware team knows what needs to be changed and that process is not blocked. The code may drive a very dirty clock signal that tells them: 1. Circuit works in the basic sense 2. Some part of the circuit doesn't work 3. Some other part of the circuit can now be added now that the basic circuit has been confirmed It's okay saying "build the entire thing perfectly", but spending the difference between one and two weeks validating that something at least has the chance of working is massive. You can't afford to block every team that needs to know whether the part you are writing is even a valid concept. This may come back down to design, but sometimes - especially with hardware, the manufacturer/API doesn't tell you the whole story and you need to know that as soon as possible to start compensating for it. I think building a rough implementation and re-factoring it is way more agile than trying to build the correct version first time, possibly leaving some unknown problem to remain undiscovered for longer. It seems backwards to me when we're talking about anything that has an element of risk.

Yes, do everything all at once. And never be able to release anything.

by btym 10y ago

Yes, do everything all at once. And never be able to release anything.

YZF 10y ago

That's not what I said. Do what needs to be done at a given point in time to release. Just don't soothe your conscience by putting a TODO in the code. 99% that TODO will never get done, it's just clutter and code smell. If your code is broken you're releasing something that's broken which is probably going to end badly. If the code is adequate then it's adequate. Often it's just perception that doing it wrong is faster than doing it right. Prefer doing it right. (EDIT- doing it right is often faster)

bArray 10y ago
I'm not sure this model works, in at least my case. Where there is perhaps some circuit you need to validate actually works with some sort of code - it's often useful to write some bad display driver for example so that the hardware team knows what needs to be changed and that process is not blocked. The code may drive a very dirty clock signal that tells them: 1. Circuit works in the basic sense 2. Some part of the circuit doesn't work 3. Some other part of the circuit can now be added now that the basic circuit has been confirmed It's okay saying "build the entire thing perfectly", but spending the difference between one and two weeks validating that something at least has the chance of working is massive. You can't afford to block every team that needs to know whether the part you are writing is even a valid concept. This may come back down to design, but sometimes - especially with hardware, the manufacturer/API doesn't tell you the whole story and you need to know that as soon as possible to start compensating for it. I think building a rough implementation and re-factoring it is way more agile than trying to build the correct version first time, possibly leaving some unknown problem to remain undiscovered for longer. It seems backwards to me when we're talking about anything that has an element of risk.