I agree in principle, but think it's possibly a good opportunity, to utilize this to create a compendium of industry practices, some of which could then be labeled as anti-patterns.
Makes sense. I hope you keep working on this. There is a big gap between what people are doing in the academic (and even publicly-described industrial literature) and what you describe. So I think there is a lot of opportunity to push on this front if you have some ideas.
A fair point, but I think that really just lends credence to what I'm suggesting, that we expand upon that, since it isn't standardized or all that useful. If you were encountering it for the first time, what would you think WntA did?
An excellent idea. We could work out a standardized format and build wikis around them. We should come up with a name too. I think "patterns" would be good.
Totally good idea to do that. I just want other readers to be aware for what applications that is useful and for what applications other techniques are more appropriate.
It's an interesting idea, but would take a fair bit of creativity to execute well I think. It's really hard to enumerate this grey area! But I think something that elaborates on this grey area with lots of examples would be great. Sounds like a blog post I should write. :)
I think an interesting angle would be a categorization by the author of what they found was useful/fluff/low quality. Would be a good way to figure out where you're wasting time vs getting value (of course sometime the point is to waste time...)
Currently, it seems most helpful in aggregating some of the arguments folks put forth in examining claims, including describing the basic issues and linking some references. Plus it seems to offer some insight into what folks are thinking.
Then from an academic perspective, I really like the sort of approach that they're trying to use. A well-developed implementation of that general approach would seem like it could be awesome.
That said, dunno if I find their current methodology or numbers too convincing, as far as actual conclusions go.
I definitely support that. Many tips I give to people for their projects came straight out of 1960's-1980's CompSci or industrial work. It has been a ridiculous amount of effort finding all of it, though. So many silos. It needs integrated on a per topic basis, cleaned up, an executive summary, and references available for follow-up. Preferably with FOSS tools if it's an analytical method, language, etc.
Then, people might quite reinventing the wheel or missing obvious things as much as they do now.
This was my first thought as well. Not a bad way to go about it, too. Maybe they'll get some data about which knowledge base articles aren't helpful, too.
Instead of a spec, I'd like a list of best practises. They would need to be sufficiently detailed that someone could verify if you are following each one.
I was watching tptacek talk on crypto/pen testing and he mentioned that a flaw published 15 years ago, is still being put into the wild by general web developers, in big companies who should know better.
And I was also reminded of the checklist manifesto - where the Boeing (?) flight safety team analyse each crash report, and produce checklists for pilots that are pushed out around the world and actually read
so here is a silly idea
A kick-starter that funds a group to guide writing of real actual best practise in software engineering - broken down into silos like realtime or web or os. It can be updated and informed wiki style but is aimed at spreading actionable, immediate choices, with the background reading to educate later on,
Agree. It is useful insofar as you can quickly get a sense of what working in a given framework feels like, but the community could use some alternatives.
reply