Your SlideShare is downloading. ×
Cinci ug-january2011-anti-patterns
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Cinci ug-january2011-anti-patterns

414
views

Published on

Anti-Patterns and Worst Practices of Software Development

Anti-Patterns and Worst Practices of Software Development

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
414
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • We learn from mistakes. Certainly we learn from our own mistakes, but we can also learn from others’ mistakes.George Santayana:“Those who fail to learn from the mistakes of their predecessors are destined to repeat them.” (paraphrased)http://en.wikiquote.org/wiki/George_Santayana
  • http://en.wikipedia.org/wiki/File:Hindenburg_burning.jpgThis image is a work of a sailor or employee of the U.S. Navy, taken or made during the course of the person's official duties. As a work of the U.S. federal government, the image is in the public domain.
  • The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A". Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay. Story:http://www.amazon.com/dp/0961454733/Image Licensed with Attribution Required:http://www.flickr.com/photos/jungle_boy/140279885/sizes/o/http://creativecommons.org/licenses/by-nc-sa/2.0/
  • It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature, I took extra care to put in place everything I had learned -- commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt so ready for came as a rude awakening -- reuse was frowned upon!How could this be?The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Those four lines of similar code were accidental, a coincidence. That is, until I cam along.
  • Image is a screenshot from my own email archives.
  • Show something jury-rigged together with duct tape
  • See also You are not the User from 97TEPSK.Also known as Programming by Coincidence in The Pragmatic Programmer
  • See also You are not the User from 97TEPSK.Also known as Programming by Coincidence in The Pragmatic Programmer
  • Tell a story about telemarketing
  • Declutter your code
  • Image provided by presenter.
  • Image Attribution:http://www.flickr.com/photos/rakka/398066964/http://creativecommons.org/licenses/by-nc-nd/2.0/deed.en
  • Image from speaker’s own system.
  • Image from speaker’s own system.
  • Image licensed for sharing with attribution:http://xkcd.com/327/http://creativecommons.org/licenses/by-nc/2.5/
  • Image licensed for sharing with attribution:http://xkcd.com/376/http://creativecommons.org/licenses/by-nc/2.5/
  • Photo is owned by speaker.
  • A couple of years ago, when I was just really starting to do lots more CSS and really didn't know what I was doing, I once spent 2, possibly 3 days, trying to create a single cross browser CSS button with rounded corners; it was an attempt to use the images the designer had supplied for all buttons. I was so focused on getting something clean and elegant and in a single stylesheet, that I completely ignored the fact that it didn't have to be clean, elegant, or in a single stylesheet; it just had to work. The lesson: clients don't care about how technically perfect your solution is and you shouldn't focus on the tiny details; get it working first, then refactor if necessary.
  • I had a customer that wanted to check addresses. The problem was how would someone handle slight name differences, such as Fort Wayne ad Ft. Wayne, or Elm Street, Elm St. or Elm Str. The PM wanted to create a very big rule based system to check for all kinds of conditions. We were brainstorming and I had a short and simple fix. As I explained it, the PM went off that my solution wasn’t a complete solution. I asked him to give me an example of how it wouldn't work. He couldn't, but he was convinced that there was a problem with my solution. I went ahead and built my solution. He wanted to spend a lot of time (weeks) to solve this one minute problem. Given that this was a startup, I told him that it didn't make sense to spend a lot of time on this problem. I went ahead and built my solution in about 1 hour. Finally, I told him that when he had an address where my solution didn't work, to show it to me and I'd update my code to resolve the issue, but that we needed to move on. Lesson: solve the 90% problem first, then solve the next problem, and then the next problem, but don't waste time on a problem to a level that no one really cares about. Startups don't need to spend weeks on a problem that has a simple solution and don't need to over complicate the solution.
  • The table has 200,000,000 rows currently · PlacementID ranges from 1 to 5000 and should support at least 50,000 · CreativeID ranges from 1 to 5000 and should support at least 50,000 · PublisherID ranges from 1 to 500 and should support at least 50,000 · CountryCode is a 2-character ISO standard (e.g. ‘US’) and there is a country table with an integer ID already.  There are < 300 rows. · RequestedZoneID ranges from 1 to 100 and should support at least 50,000 · AboveFold has values of –1, 0, or 1 only. · Period is a date (no time). · Clicks range from 0 to 5000. · Impressions range from 0 to 5000000. · The table is currently write-mostly.  Its primary purpose is to log advertising activity as quickly as possible.  Nothing in the rest of the system reads from it except for batch jobs that pull the data into summary tables.