Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts

Tuesday, July 20, 2010

A/B Testing and Groundhog Day

Blog post at Coding Horror

Phil doesn't just go on one date with Rita, he goes on thousands of dates. During each date, he makes note of what she likes and responds to, and drops everything she doesn't. At the end he arrives at -- quite literally -- the perfect date. Everything that happens is the most ideal, most desirable version of all possible outcomes on that date on that particular day. Such are the luxuries afforded to a man repeating the same day forever.

But at the end of this perfect date, something impossible happens: Rita rejects Phil.

Phil wasn't making these choices because he honestly believed in them. He was making these choices because he wanted a specific outcome -- winning over Rita -- and the experimental data told him which path he should take. Although the date was technically perfect, it didn't ring true to Rita, and that made all the difference.

While I think the analogy between Groundhog Day and A/B testing is perfect, I disagree with the conclusion that "A/B testing is like sandpaper. You can use it to smooth out details, but you can't actually create anything with it."

I would argue that A/B testing is useful because it reveals what people actually prefer, rather than what they say they prefer. Often there is quite a gap between the two. Also, as many of the commenters pointed out, A/B testing is just a tool - you don't have to limit yourself to testing tiny, incremental tweaks. You can creatively explore the world of possibilities, while basing your final choice on hard data.

As one commenter pointed out, the analogy to Groundhog Day breaks down because at the end of the day, "It's a movie. She rejects him, not because of some inherent failure in the method he uses, but because it was written that way in the script."

Sunday, July 19, 2009

Craftsmanship, not engineering

Post at Coding Horror, "Software Engineering: Dead?"

What DeMarco seems to be saying -- and, at least, what I am definitely saying -- is that control is ultimately illusory on software development projects. If you want to move your project forward, the only reliable way to do that is to cultivate a deep sense of software craftsmanship and professionalism around it.

The guys and gals who show up every day eager to hone their craft, who are passionate about building stuff that matters to them, and perhaps in some small way, to the rest of the world -- those are the people and projects that will ultimately succeed.

Everything else is just noise.

Thursday, April 2, 2009

Anti-carpal tunnel exercises

Video is by a professional percussionist, but applies to desk jockeys as well.

Saturday, February 28, 2009

Technical Debt

CodingHorror blog post

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

Serious bonus points for including a quote from Dune, by Frank Herbert
I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.

Tuesday, February 17, 2009

Elegant? Or under deadline, under budget, just works?

Post on The Daily WTF

Only a select few get paid to develop “sexy” software, whereas most of us are stuck developing the boring stuff.

There’s a term for this type of boring software: information systems. And while the purpose of an information system changes from company to company, as do the specific requirements, they all are essentially the same. There’s a database that models the real world, rules to define how the data may be changed, an interface to the database, and lots of different reports.

As Michael A. Jackson said in his 1975 Principals of Program Design, “Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill.”

This thirty-five year-old observation is confirmed day-in and day-out here on TDWTF. Some of the most egregious code and stories written here stem from the developer’s desire for cleverness. Carrying out these desires is neither malicious nor devious, but merely instinctual.

Essential rules that must be followed when developing business information systems:
  1. Learn the business
  2. Serve the business
  3. Learn off the job
  4. Code mostly business
  5. Tedium is inescapable
  6. Find satisfaction elsewhere
  7. Get another job

Friday, December 19, 2008

Programmer's Bill of Rights

I would say this goes for anyone analyzing data, as well.

Blog post by Jeff Atwood of Coding Horror
  1. Every programmer shall have two monitors
  2. Every programmer shall have a fast PC
  3. Every programmer shall have their choice of mouse and keyboard
  4. Every programmer shall have a comfortable chair
  5. Every programmer shall have a fast internet connection - Good programmers never write what they can steal.
  6. Every programmer shall have quiet working conditions - Programmers cannot work effectively in an interrupt-driven environment.
The few basic rights we're asking for are easy. They aren't extravagant demands. They're fundamental to the quality of work life for a software developer. If the company you work for isn't getting it right, making it right is neither expensive nor difficult. Demand your rights as a programmer! And remember: you can either change your company, or you can change your company.

Hardware is Cheap, Programmers are Expensive

Blog post by Jeff Atwood of Coding Horror

Given the rapid advance of Moore's Law, when does it make sense to throw hardware at a programming problem? As a general rule, I'd say almost always.

Incidentally, this is also why failing to outfit your (relatively) highly paid programmers with decent equipment as per the Programmer's Bill of Rights is such a colossal mistake. If a one-time investment of $4,000 on each programmer makes them merely 5% more productive, you'll break even after the first year. Every year after that you've made a profit. Also, having programmers who believe that their employers actually give a damn about them is probably a good business strategy for companies that actually want to be around five or ten years from now.

...

Programmers have a tendency to get lost in the details of optimizing for the sake of optimization... If you're not extremely careful, you could end up spending a lot of very expensive development time with very little to show for it. Or, worse, you'll find yourself facing a slew of new, even more subtle bugs in your codebase.

Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
- M.A. Jackson

Monday, December 8, 2008

Genetic Algorithms and the Mona Lisa

Link to blog post by Roger Alsing

50 semi-transparent polygons, with vertex locations and color being determined by a genetic algorithm - evaluation function is a comparison to the actual Mona Lisa.

What's instructive here is the simplicity of the model: 4 parameters per polygon - 3 vertices and the color, for a total of 200 parameters. I'm guessing the evaluation consists of summing all the polygons and then doing some kind of image comparison - wonder how fast it runs?

The final result appears after close to a million iterations...but recognizable image occurs around 100,000 generations. Also, comments point out that the algorithm does not appear to be a standard "genetic" algorithm, but instead a stochastic hill-climbing algorithm.

Update:
FAQ by Roger Alsing
Source code
A Clojure version of the same approach

Another update:
A very detailed look at optimizing this image compression approach