michaelfeathers

15 ms·

91.
by michaelfeathers 10y ago
I look at property-based testing the same way I look at Design by Contract. It can be used to find errors in existing systems, but it's also valuable when you are designing. Just asking yourself what laws a function should adhere to as
92.
by michaelfeathers 10y ago
Nick, I think that the primary win is referential transparency. APL idioms raise the level on that base. The tradeoff, though, is the same as we have for functional but further along the road: if you develop a codebase that doesn't use
93.
by michaelfeathers 10y ago
> Not sure where to go from here. For the past few years I've been telling people about the APL family of languages. The clincher for me was seeing the video of an APL version of Conway's Life mentioned in the submission. The i
94.
by michaelfeathers 10y ago
I agree. My argument isn't against exploratory testing but rather against the idea that developers shouldn't also be cultivating that way of seeing systems.
95.
by michaelfeathers 10y ago
As a developer you should be thinking through your edge cases more than a tester would. The alternative is needing more testing. Ideal situation: tester doesn't find anything.
96.
by michaelfeathers 10y ago
For higher level tests that's fine. At the unit level it's problematic. It delays feedback.
97.
by michaelfeathers 10y ago
I don't think this is a good way of framing things. In fact int can be counter-productive. Automated testing is the process of writing code to understand your code. We already have to understand our code. Testing is being deliberate ab
98.
by michaelfeathers 10y ago
Stance detection is nice but does anyone know of any effort to evaluate text based on Russell Conjugation? https://www.edge.org/response-detail/27181
99.
by michaelfeathers 10y ago
> I've always thought that AWK's most important feature is its self limiting nature I agree. This idea doesn't receive enough attention. If you pick your constraints you can make a particular envelope of uses easy and ones
100.
by michaelfeathers 10y ago
Products are more often sidelined by technical debt than they are killed by it. A typical scenario is: 1) Product becomes too hard to change but has many existing customers 2) Product is off-shored, and costs of maintenance are under-estima
101.
by michaelfeathers 10y ago
The cost of not having employee turnover can be substantial also. It would've been interesting to see this addressed. In some particularly bad cases, organizations atrophy and lose the ability to respond well.
102.
Twitter, Reddit and Conway's Law(michaelfeathers.silvrback.com)
2 points by michaelfeathers 10y ago|0 comments
103.
by michaelfeathers 10y ago
It's staggering to think about how many layers there are now. It needs an xkcd graphic.
104.
by michaelfeathers 10y ago
http://www.catb.org/jargon/html/H/ha-ha-only-serious.html
105.
by michaelfeathers 10y ago
Confirmation bias. Once you start looking for confirmation bias you see it everywhere.
106.
Toward a Galvanizing Definition of Technical Debt(michaelfeathers.silvrback.com)
2 points by michaelfeathers 10y ago|0 comments
107.
by michaelfeathers 10y ago
The key insight is that immutability is not an end in itself, it's a tool to give us referential transparency. If a language can allow mutability in an area of code without allowing side effects to escape from it we can have all of the
108.
by michaelfeathers 10y ago
Agreed. Breaking changes can lead to alienation of user base, but I think there's a danger in lulling people into expecting that kind of constancy in software. It creates dependency of another kind. Maybe the trick is to vary features
109.
by michaelfeathers 10y ago
That's Postel's Law.
110.
by michaelfeathers 10y ago
> If you build a system that doesn't deal with spam, it gets drowned in spam. If you build a system that doesn't deal with abuse, abuse becomes commonplace. If you don't secure your IoT devices you get journalists DDoSed b
111.
by michaelfeathers 10y ago
I'd want to see an automated test suite for the build.
112.
by michaelfeathers 10y ago
I think the 'ravioli code' moniker is really a slight on good code. It just takes some time to become acclimated to the style of having many smaller pieces. That said, over-engineering is real. Unnecessary layering should go away.
113.
by michaelfeathers 10y ago
> That doesn't even address the hard part. Fair enough. I did write a book on the other parts, though. https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...
114.
by michaelfeathers 10y ago
The thing about unit testing existing code is that it is much easier than most people think: https://michaelfeathers.silvrback.com/characterization-testi...
115.
by michaelfeathers 10y ago
The modern equivalent is called 'ravioli code' http://c2.com/cgi/wiki?RavioliCode "thousands of little classes everywhere and no one knows how to find the places where things really happen."
116.
by michaelfeathers 10y ago
I think the industry is on the cusp of settling on the Erlang model which is essentially allowing pieces of a program to crash so that the whole program doesn't have to. It will take time for practices and tools to spread.
117.
by michaelfeathers 10y ago
> but it's still a gotcha for the audience this blog post is aimed at. Would be nice if they had a pointer to the reason, however.
118.
by michaelfeathers 10y ago
The behavior of 'assert' is not an anomaly. It comes from 'design by contract.' Assert is primarily meant to be documentation of constraints in code and secondarily a way of catching errors during development. "Cont
119.
by michaelfeathers 10y ago
Exactly.
120.
by michaelfeathers 10y ago
The experience of other language communities is: you'll get used to it. When C# introduced its version of this with the 'var' keyword many felt that code would become less clear but, in general, context gives you what you nee

More ›