Worst Practices: Stories Wanted

[Steven Smith]

I know some of the 97TEPSK reference lessons learned and "worst
practices." I'm giving a talk at TechEd on anti-patterns and worst
practices and I'm hoping to leverage others' experience and tell some
stories about what the consequences can be when things go wrong.
These need not be code specific (or Microsoft platform specific) at
all, so long as they're software development related. I need to have
a rough idea of my presentation and slides in the next couple of
weeks, I think, so I'd like to hear from anybody interested in sharing
their experience with me by the end of next week if possible. I'll
happily credit you during the talk.

Thanks!
Steve

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis

[Michael Loukides]

Just remember to hold up the book! And tell people to buy it.

I'm really not the person who should be answering this question, but I keep on being astounded by the things I see or hear about. About 10 years ago, someone told me about hiring a "certified Java programmer" whose previous job had been managing a McDonald. He gave him an assignment, and the guy came back with a 20K line main method. I laughed about it at the time, but in the past week, I saw something really similar (it was fairly widely tweeted). The code started with about 150 lines of imports, and got worse from there.

Mike

> --
> To view or edit your contributions, visit http://programmer.97things.oreilly.com
> To post to this group, send email to 97things-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/97things-programmer?hl=en
>
> To unsubscribe, reply using "remove me" as the subject.

[Timothy High]

For starters, I'd say you should do your research in the unofficial library of worst practices: http://thedailywtf.com/

Unfortunately, they're not well catalogued, but every now and then he comes up with a phrase that gets used over and over like an antipattern, such as the "developmestuction environment": http://thedailywtf.com/Articles/The_Developmestuction_Environment.aspx

I started my own series on my blog of what I call "Causes of Decay" - reasons that a code base goes sour - But I didn't get very far. They're not anti-patterns, per se, but you might be able to get something out of that: http://timhigh.wordpress.com/tag/causes-of-decay/

I based my idea for that series on Joe Yoder's seminal article, "Big Ball of Mud", that does a great job of explaining why things can go awry in the code base: http://www.laputan.org/mud/mud.html (he also explains that often it's a trade off someone's making - not just blind bad practices).

I also think that good programming/design is a walk on the fence between "not looking ahead" at all (doing the simplest thing without any care for future maintenance) and over-design (making EVERYTHING flexible until it's a humpty dumpty that no one, not even the original author, can put back together again). Scott Bain does a great job of explaining how to walk that fence using simple practices he calls "Emergent Design" http://www.netobjectives.com/emergent-design-evolutionary-nature-professional-software-development. Over and under-design would, of course, be bad practices. I once worked on a project with a guy that was so enamored with design patterns and Spring that pretty much every method was a separate class, and every class was interchangeable with another implementation via the Spring config. The result: a configuration file the size of the original source code, no way to "follow" the code execution in the IDE because everything was loosely connected via interfaces and implementation injection, and a lot of head scratching just to get the thing running. For the installation guide, we did our best to gloss over the details...

I'll let you know if anything else leaps out at me from my own experience.

Tim.

[Steven Smith]

Thanks, Tim! I've also collected a bunch of anti-patterns here:
http://stevesmithblog.com/blog/principles-patterns-and-practices-of-mediocre-programming/

and after posting that someone pointed me here as well:
http://c2.com/cgi/wiki?AntiPatternsCatalog

I've already read the Big Ball of Mud article and am planning on
discussing it, too. I'll check out the other links you posted and
looking through TheDailyWTF is also a good idea (though I'm hoping to
use stories from people I've personally corresponded with - if I find
something good I'll try to contact the author).

Thanks,
Steve

[Steve Berczuk]

The thing to remember about big ball of mud is that it's about how NOT to make the code system equivalent of a shantytown. 

I don't particularly like the concept of anti pattern as it doesn't help build something. If you use the negative examples as a basis for understanding how things can go wrong and what to do to mitigate the risk that's helpful. Otherwise it's just ranting. 

Speaking of which, I realize that this is a bit of a rant inspired by some of the conversations I had about patterns and antipatterns in the late 90s. 

But in the spirit of 97tepsk let me suggest that it's anti patterns are most useful as motivating examples for patterns. 

Steve

[Matt Doar]

Carrot and stick, carrot and stick. I find anti patterns useful only as warning signs that Bad Things are happening. I agree they don't show me how to do it better, but I don't think that's their intention.

~Matt

[Steve Berczuk]

Yeah. Agreed. I think the presentation in Steve's blog is in the spirit of why I said. 

I guess I mostly object to the name anti-pattern. The opposite of a pattern isn't per se a bad thing as patterns have context and in a different context a pattern like solution may be anti.  

And the name anti-pattern doesn't actually say anything.  

But this is getting philosophical:) I'm guessing that everyone here is interested in improvement not just complaining about bad code. 

Steve

[Daniel Lindner]

Steven Smith wrote:
> I know some of the 97TEPSK reference lessons learned and "worst
> practices." I'm giving a talk at TechEd on anti-patterns and worst
> practices and I'm hoping to leverage others' experience and tell some
> stories about what the consequences can be when things go wrong.
> These need not be code specific (or Microsoft platform specific) at
> all, so long as they're software development related. I need to have
> a rough idea of my presentation and slides in the next couple of
> weeks, I think, so I'd like to hear from anybody interested in sharing
> their experience with me by the end of next week if possible. I'll
> happily credit you during the talk.
>
>

Hi Steven,
this isn't a story, but content I include in my software engineering
lectures that gets good feedback:
Top 25 Most Dangerous Programming Errors
(http://cwe.mitre.org/top25/index.html)
This sounds like an oversized Top X blog entry first, but is an ongoing
project to identify the most common (and worst) programming errors made
in the field. I would refer to them as "worst practices".

There is one little story I can share as a direct witness:
Not too long ago, a neighbourly company called for our help on a project
that was late and oversized. It was a software handling money in the
banking domain. We asked them to perform an in-depth code review with us
so we can decide if we can add value to the project or just serve as
additional ballast. During the code review, we've seen many coding sins,
but one of them really was a worst practice (it convinced us to refuse
to join in):
All the values (should I say quantities?) in the program were stored in
floating point fields. They never heard about the concept/pattern of
"Quantities" (refer to Martin Fowler's "Analysis patterns" book). And
they ignored the fact of precision errors.

The worst practice in this story is the total ignorance about basic
numerical issues with today's computers. There are already workable
solutions for many of them, you just have to be aware about the problem
and the solution.

Today, I would perhaps call them the avant-garde of the BASE movement
(summed up nicely here:
http://www.johndcook.com/blog/2009/07/06/brewer-cap-theorem-base/)
without a database (and a clue).

Sincerely, Daniel

[Marcus Baker]

Hi...

Steve Berczuk wrote:
> I don't particularly like the concept of anti pattern as it doesn't help
> build something. If you use the negative examples as a basis for
> understanding how things can go wrong and what to do to mitigate the
> risk that's helpful. Otherwise it's just ranting.

Not sure I agree with this. A lot of times people don't even realise
they are doing anything wrong. An anti-pattern as a war story with the
resulting consequences is really useful. Probably why we find them so
fascinating.

Saying that it's ranting to describe the negative is a bit like saying
that you have nothing to learn from reading an account of Chernobyl.

Taking a more scientific tack, check out some of the social science
complexity stuff, in particular "sense making". Domains like the
military or the business world can only describe negative "war" stories.
Any plan is worthless once it's been revealed to the enemy/competitor.
You are left with lots of what not to do's, such as don't go into battle
without ammo, but no prescribed path to victory or profit.

We don't live in the business/warfare domain, our stuff is more like
research, but we touch upon it.

> Steve

yours, Marcus

[Kevlin Henney]

On 3 April 2010 18:39, Marcus Baker <mar...@lastcraft.com> wrote:
> Steve Berczuk wrote:
>> I don't particularly like the concept of anti pattern as it doesn't help
>> build something. If you use the negative examples as a basis for
>> understanding how things can go wrong and what to do to mitigate the
>> risk that's helpful. Otherwise it's just ranting.
>
> Not sure I agree with this. A lot of times people don't even realise
> they are doing anything wrong. An anti-pattern as a war story with the
> resulting consequences is really useful. Probably why we find them so
> fascinating.

Unfortunately, fascination does not always equate to learning.
Learning requires something else in addition. There is a myth about
learning from mistakes that doesn't stand up to close scrutiny, which
is a point I make in the middle section of the following talk:

http://qconlondon.com/london-2010/file?path=/qcon-london-2010/slides/KevlinHenney_PatternsForThePeople.pdf

People that are learning from mistakes are doing something else as
well, otherwise they would typically fail to learn and adapt their
behaviour.

Kevlin
--
________________________

Kevlin Henney
+44 7801 073 508
http://curbralan.com
http://kevlin.tel
________________________

[Steven Smith]

Thanks, Daniel!

> --
> To view or edit your contributions, visit
> http://programmer.97things.oreilly.com
> To post to this group, send email to 97things-...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/97things-programmer?hl=en
>
> To unsubscribe, reply using "remove me" as the subject.
>

--

[Steven Smith]

Hi Steve,
I definitely agree with your point and it is certainly my intention
to share these "war stories" for the purpose of letting the audience
learn from others' mistakes. I also intend to make the point that
context is key. There are plenty of patterns that are best practices
in one context and worst practices (anti-patterns?) in others. Sadly
it often requires experience to know whether the context makes a given
approach applicable or not, but to some extent I believe it is
possible to learn from others' experience rather than solely through
one's own experience, hence my desire to present on this subject.

Best regards,
Steve

[Timothy High]

At least at the architectural level, the people at SEI are trying to change this by defining patterns as "ABAS" - Attribute-Based Architectural Styles. The point is that if you examine a pattern closely enough, you can see the impact it will have, for example by trading performance for flexibility. Rather than look at patterns in isolation, they then look at the quality attributes in isolation - if you have 5 patterns that affect (a particular type of) performance, and you can define an equation for each one, then you can see how the combination will look as a whole (and how each pattern has an impact).

Part of the problem with this is that not every decision we make is worth doing that kind of math. But a large part of it is that we aren't trained and we don't practice looking at our decisions that way, so these equations and the inputs they require are so inaccessible that it turns such an activity into a complete effort in futility. It's possible to see how these patterns will work in context without the requisite experience, but it's far from being a reality.

Tim.