4 ms·
>> And here is that insidious problem; all your unit tests have frozen the interaction of your components. They have copied the API of your components and dist
by lhnz 13y ago
>> And here is that insidious problem; all your unit tests have frozen the interaction of your components. They have copied the API of your components and distributed it all over your test code base.
This is what I hate about the unit-test everything approach. There seems to be a class of developers recently that believe robustness is more important than anything else.
Often speed bumps in changing API contracts is a higher price to pay [0] than the kind of bugs which unit testing uncovers.
There are lots of things which are good in small quantities and very bad in large quantities [1].
Better to be able to iterate quickly, spot a few bugs with sparse unit tests and completely rewrite your small components if they no longer fit the bill. There is a tendency (perhaps with those too familiar with large corporates) to try to de-risk with more and more robustness tests. With all of this robustness monolithic software flourishes, and you eventually lose the ability to iterate quickly; the ability to destroy and start anew.
[0] Form does not follow function, form is interdependent with function. Make the functionality robust and you make the form rigid! How will you find product-market fit when you are unable to move?!
[1] http://en.wikipedia.org/wiki/Hormesis http://en.wikipedia.org/wiki/Hormesis
- DanWaterworth 13y agoIt's better to do the wrong thing quickly.
- angersock 13y agoEh, you'll have an annoying time putting a man on the moon with that attitude. But hey, your twitters will hockeystick better! It all depends on your problem domain--the cost of failure for certain things (pacemakers, telco software, car engine ECU code, and so on) may be much, much greater than the cost of being super retentive in your development.
- lhnz 13y agoYes, it depends on the domain but outside a few industries (and low-level code) software isn't a life-or-death matter. Infrastructure is a different kettle of fish, while it might sometimes be a life-or-death matter, generally it's just safer to seek pure robustness here: monopolies with government connections do not need to fear losing competitiveness since they can (a) manipulate the rules of the market, and (b) bind market players with contracts. I don't like your insinuation that I'm just talking about cool hockey-stick startups; in the domains in which non life-or-death, free-market business and software colide, losing competitiveness/product-market fit is the central failure mode. And you absolutely cannot become robust against the market. You must either (1) become faster than the market, or you must (2) control the market.
- apalmer 13y agoTrue indeed but the initial comment of 'It's better to do the wrong thing quickly.' was stated without nuance or caveat so the reply rightly pointed out that this statement is true in certain domains and completely false in others.