Jeff Atwood, of “Coding Horror” fame, once something like “If our code didn’t use abstractions, it would be a convoluted mess“. As software projects get larger and larger, using more and more abstraction technologies is the key to creating robust and maintainable code.

Using C++ as an example language, the figure below shows the advances in abstraction technologies that have taken place over the years. Each step up the chain was designed to make large scale, domain-specific application development easier and more manageable.

The relentless advances in software technology designed to keep complexity in check is a double-edged sword. Unless one learns and practices using the new abstraction techniques in a sandbox, haphazardly incorporating them into the code can do more damage than good.

One issue is that when young developers are hired into a growing company to maintain legacy code that doesn’t incorporate the newer complexity-busting language features, they become accustomed to the old and unmaintainable style that is encrusted in the code. Because of schedule pressure and no company time allocated to experiment with and learn new language features, they shoe horn in changes without employing any of the features that would reduce the technical debt incurred over years of growing the software without any periodic refactoring. The problem is exacerbated by not having a set of regression tests in place to ensure that nothing gets broken by any major refactoring effort. Bummer.

I swear it's all their fault...

The first rule of being a programmer is that its always your fault.

If there is a *bug* in the application then more than likely it’s a bug in your code.  This is a lesson you learn over and over and over when you are a new programmer.  Trust me, I can’t count the number of times I thought “Well there must be something wrong with this api or this library that I’m using because it doesn’t work right with my program”.  Only to later discover what I should have known all along….the problem is of course with the code I’ve written, sometimes its something very small, sometimes something big.  That’s the thing with programming, web development in my case, no matter how small a *bug* is it can drive you crazy trying to find it.

Here is the First Rule of Programming: It’s Always Your Fault by Jeff Atwood of Coding Horror

Predictably Irrational, by Dan Ariely, is a fascinating collection of research about decision-making psychology.

Above is a great video produced by FORA.tv of Ariely, a professor of behavioral economics at Duke University, presenting examples of cognitive illusions during last year’s The Entertainment Gathering (EG).

Over at Coding Horror, Jeff Atwood (no relation, though my brother has the same name) explains “nine ways marketing weasels [use behavioral economics] to manipulate you” and “how we can avoid falling in the rut of predictably irrational behavior”:

#3: It’s “Free”!

Ariely, Shampanier, and Mazar conducted an experiment using Lindt truffles and Hershey’s Kisses. When a truffle was $0.15 and a kiss was $0.01, 73% of subjects chose the truffle and 27% the Kiss. But when a truffle was $0.14 and a kiss was free, 69% chose the kiss and 31% the truffle. According to standard economic theory, the price reduction shouldn’t have lead to any behavior change, but it did.

Ariely’s theory is that for normal transactions, we consider both upside and downside. But when something is free, we forget about the downside. “Free” makes us perceive what is being offered as immensely more valuable than it really is. Humans are loss-averse; when considering a normal purchase, loss-aversion comes into play. But when an item is free, there is no visible possibility of loss.

You will tend to overestimate the value of items you get for free. Resist this by viewing free stuff skeptically rather than welcoming it with open arms. If it was really that great, why would it be free?

Free stuff often comes with well hidden and subtle strings attached. How will using a free service or obtaining a free item influence your future choices? What paid alternatives are you avoiding by choosing the free route, and why?

How much effort will the free option cost you? Are there non-free options which would cost less in time or effort? How much is your time worth?

When you use a free service or product, you are implicitly endorsing and encouraging the provider, effectively beating a path to their door. Is this something you are comfortable with?

More about Ariely and his must-read book can be found at the official Predictably Irrational website.

StackOverflow was started around December 2008 and has quickly become the go-to location on the internet to ask technical questions.

It was started by Joel Spolsky and Jeff Atwood, two bloggers that I keep on my blogroll and are some of the top software development bloggers in the world.

The StackOverflow DevDays is a conference started to bring together the large community of users on StackOverflow to talk about new technology and trends. The topics covered at the conference are the following:

Android; Objective-C; iPhone SDK; Google App Engine; jQuery; ASP.NET MVC; FogBugz; Python; JavaScript; Mercurial; DVCS

Of the topics being discussed, I’ve played with jQuery, ASP.NET MVC (beta 3 and 4), Python, JavaScript, and Mercurial. I’m not too sure why FogBugz has a mention here, since it doesn’t seem to fit. Here are the logical categories that I’ve grouped the topics into:

Operating Systems / SDKs: Android; iPhone SDK

Programming Languages: Objective-C; Python; JavaScript

Frameworks: Google App Engine; jQuery; ASP.NET MVC

Distributed Version Control Systems: Mercurial; DVCS

Which one doesn’t fit? FogBugz, which is a bug tracking system created by FogCreek Software, owned by Joel Spolsky. I hope the talk on FogBugz isn’t just a marketing pitch.

Anybody else going? Let me know and I’ll keep an eye out for you.

Dan an I had the pleasure of going to the open house at Fog Creek and meeting Joel Spolsky. Their office space, people and culture seem to be everything Joel boast of in his blog. Joel on Software is one of the most read development blogs out there. Dan introduced me to the blog about a year ago and I find it to be very useful and entertaining. Having seen first hand how cool it really is makes it hard to come back to my cube at the very conservative company I work for. Coming from the South and having to develop websites and applications for “Boss Hog”, I really dig cutting edge vibe. How great would it be to work with happy, smart and cool people? It’s why I moved to New York.

We also had the pleasure of meeting Dan, one of their developers and a few other very friendly and outgoing people. The food was great. They had huge party subs, chips, chicken fingers, chocolate covered strawberry’s, brownies, macaroni and cheese, all kinds of drinks and really good coffee. They told me where the dude was from that was making the lattes but I can’t remember now. He does the trick of making the milk foam into a pattern of a fern. Very nice.  Just can’t beat free lunch, super cool people and a great view. Check out Joel’s blog for photos of the office. The photos below were taken with Dan’s camera phone. I really need to buy a camera.

They make FogBugz, a bug tracking system that actually works and can be used to manage everything your development team does, from bug tracking to customer email to feature management to project scheduling and so much more. Free online trial.

They also make Fog Creek Copilot, which lets you control someone else’s computer (with their permission, of course) over the Internet. It’s the best way to fix someone’s computer problems remotely. There’s nothing to install, it’s simple as heck, and it works through any kind of firewall, NAT, or proxy situation with zero configuration. More

Joel also has a weekly podcast with Jeff Atwood and they chat about software development and the new developer Q&A website we built, stackoverflow.com.

Fog Creek :: Dan, Joel, and Brenda

Brenda Kato at Fog Creek

It all started with this post by Jeff Atwood:

“…Let’s say, hypothetically speaking, you met someone who told you they had two children, and one of them is a girl. What are the odds that person has a boy and a girl?…”

More comments on his next post as he answers:

“…Most people answer 50%.

Unfortunately, this isn’t correct.

This problem, although seemingly simple, is hard to understand. For cognitive reasons that are not fully understood, while our intuitions regarding a priori possibilities are fairly good, we are easily misled when we try to use probability to quantify our knowledge. This is a fancypants way of saying there were almost a thousand comments on that post, with not a lot of agreement to be found.

The key thing to bear in mind here is that we have been given additional information. If we don’t use that information, we arrive at 50% — the odds of a girl or boy being born to any given pregnant woman. That’s true insofar as it goes, but it’s the answer to a different, much simpler question, and certainly not the answer to the question we asked…”

okay. I guessed 50% also. But I’m not an expert of Bayesian probabality. Guess who disagreed with Jeff Atwood?

Give up?

Paul Bucheit, founder of Gmail begged to differ with Jeff Atwood. Nice. In his blog post THE QUESTION IS WRONG:

“…The problem with the question as originally posed was that it didn’t specify which of these algorithms was being used. Were we arbitrarily told about the girl, or was a selective process applied?

By the way, if we’re applying a selective process, then 100% is also a possibly correct answer, because at step two we could have eliminated all parents that don’t have both a boy and a girl. Likewise, all other probabilities are also potentially correct depending on the algorithm applied…”

hahaha. wow. you have to read the whole blog post to see the answers. But wait!

Rob Dickerson weighs in:

“…So, as far as I can tell, the real answer is that we don’t know enough about the mother’s behavior to give a definitive answer of how this scenario plays out on average.

Of course, this kind of reasoning is pretty tricky to pull off correctly, so I wouldn’t be surprised if a good counter arises. But I’ve thought about this problem for a while, and, for now at least, I’m pretty thoroughly convinced that this solution is correct….”

and in a later post, he even posts pictures! (I LOVE PICTURES!):

oh wow. there’s more pictures to illustrate Rob Dickerson’s answer. Feel free to view it here!

LESSON: Sometimes you can’t figure the answer becasue you DIDN’T KNOW what the question was! hahaha

Too much Bayesian Probability for a day? Maybe a very, very, very practical application (how to board a plane quickly!) of Markov chain Monte Carlo simulation?

UPDATE:

just saw a more “appropriate” version of this on HN:

“…What do you think of this story? I get a frantic call from my friend at the airport. He’s been captured by the TSA for bringing a nose hair trimmer onto the plane. He was taking his brothers two kids (whom I know nothing of) back home, but now needs me to pick them up at the airport. The line goes dead. I show up at the airport and there are 4 pairs of children waiting behind the glass to be claimed, conveniently arranged in pairs of GG, GB, BG, and BB. Each pair is equally likely to be the one I am supposed to pick up.

If my friend had told me “their names are Sarah and–” before the line went dead, I would mentally eliminate BB. Sarah could be any of the four girls. The three remaining options are not equally likely to contain Sarah, because the first one has two girls, and either one could be Sarah. So, the probability of Sarah being the girl in BG is 1/4 and of being the girl in GB is 1/4. The probability of the other child being a girl is also 1/2. It’s not so much that BG or GB is eliminated in this case, but that the probability of her being in the GG group is better. But wait a second, I am not trying to find Sarah, I am trying to find the pair of kids that is his pair of kids. Is the probability that a group contains Sarah different from the probability that a group of kids is his? Maybe that’s my bad assumption…maybe “at least one is a girl” is some precise formulation I don’t understand that means the GG group isn’t twice as likely to contain that girl. I’ll get back to that. (Possibly her name is “at least once”?).

But what if he instead told me something over the phone that would eliminate the possibility of it being two boys only? What if when he had looked out over the groups of children waiting to be picked up before they blindfolded him and panicked and said “it’s not the two boys–”? Is knowing that one of the children is a girl different from knowing they both aren’t boys? I think it is, because the latter is a statement about the set of events, and the former is a statement about a single event. When we talk about the pairs of children, the set of events, we are not conveying direct information about the individual events. In this second case he is not conveying information about the individual events and the three remaining choices remain equally likely, 1/3 each.

Looking back to “at least one is a boy”- if we interpret that as a statement about the sets of probabilities, I would more precisely restate Eliezer’s question as “Does the set of two children contain at least one boy?”. This is why the important part of the story is the word “mathematician”. The mathematician is talking about eliminating sets of events when he says “Yes”. Ordinary people would just talk about the gender of a child…”

well? was that better?

To begin I can only quote Steve Yegge’s voluminous body of work recently, I was struck by a 2005 entry on practicing programming from the original posting at Coding horror:

Contrary to what you might believe, merely doing your job every day doesn’t qualify as real practice. Going to meetings isn’t practicing your people skills, and replying to mail isn’t practicing your typing. You have to set aside some time once in a while and do focused practice in order to get better at something.I know a lot of great engineers — that’s one of the best perks of working at Amazon — and if you watch them closely, you’ll see that they practice constantly. As good as they are, they still practice. They have all sorts of ways of doing it, and this essay will cover a few of them.

The great engineers I know are as good as they are because they practice all the time. People in great physical shape only get that way by working out regularly, and they need to keep it up, or they get out of shape. The same goes for programming and engineering.

I only partially belive this. Yes, practice makes perfect and it is the only way you can get better at something. But I disagree that coding at work, for example, is not practice. It does help you get better. It might not be the best, most perfect practice, but it is practice nonetheless. And lets not forget the fact that many jobs involve going just slightly beyond your skill set. A step ahead.

But the idea of a coding Kata intrigues me. A kata is “a series of choreographed practice movements”, barrowed from marital arts.

The steps steve presents are interesting. He deviates from the normal theory of practicing strictly coding assignments and delves into more complex routines. Things like reviewing resumes, reading the code of other people regularly, and picking a profession you know nothing about and asking a professional to explain it to you. These are just some of the steps toward bettering yourself off as far as communication in the programming field. Coding Horror argues that communication is just as, if not, more important than the actual coding skills themselves. Which seems to make sense in todays large programming teams: in order to get anything done, everyone must collaborate and the only medium between that is communication.

Me encuentro ocasionalmente con ideas reveladoras. Las leo y noto como si un grupo de neuronas aletargadas se activasen de repente, haciéndome pensar en algo en lo que no había pensado antes.

La última la he leído en el artículo de Jeff Atwood “Strong Opinions, Weakly Held“, algo así como “Opiniones firmes, mantenidas débilmente”. El artículo es una defensa frente a otro artículo, “Blogging Horror“, que acusa a Jeff Atwood de haber perdido credibilidad emitiendo opiniones desinformadas sobre diversos temas relacionados con la programación. Esta discusión tiene una ramificación española, a través de una entrada en VELOCIDAD DE ESCAPE, que apareció en la portada de menéame y fue contestada por Ricardo Galli, entre otros.

El título del artículo de Atwood se refiere a una idea expresada en otro artículo del mismo nombre, cuya idea central se resume en este párrafo:

A couple years ago, I was talking the Institute’s Bob Johansen about wisdom, and he explained that — to deal with an uncertain future and still move forward – they advise people to have “strong opinions, which are weakly held.” They’ve been giving this advice for years, and I understand that it was first developed by Institute Director Paul Saffo. Bob explained that weak opinions are problematic because people aren’t inspired to develop the best arguments possible for them, or to put forth the energy required to test them. Bob explained that it was just as important, however, to not be too attached to what you believe because, otherwise, it undermines your ability to “see” and “hear” evidence that clashes with your opinions. This is what psychologists sometimes call the problem of “confirmation bias.”

que traducido por mí dice:

Hace un par de años, le estaba hablando a Bob Johansen [del Instituto de para el Futuro de Palo Alto] sobre la sabiduría, y él me explicó que – para tratar con la incertidumbre del futuro y aún así seguir avanzando – recomendaban a la gente que tuviese “opiniones firmes, que se mantuviesen de forma débil.” Llevaban dando este consejo durante años, y por lo que entiendo había sido inicialmente desarrollado por el director del Instituto Paul Saffo. Bob me explicó que las opiniones débiles eran problemáticas porque no inspiran a la gente a desarrollar las mejores ideas posibles para ellas. Bob me explicó que era igualmente importante, sin embargo, no sentirse demasiado ligado a tus ideas porque, de otra forma, socava tu habilidad para “ver” y “oír” las evidencias que choquen con tus opiniones. Es lo que los psicólogos llaman a veces el problema del “sesgo de confirmación.”

Cuando expreso una opinión en un ambiente formal (en el trabajo, en una discusión seria…), siempre intento hacerlo dejando claro que esa opinión se aplica a un ámbito concreto, que es posible que sea errónea en casos que no he contemplado y que por lo tanto admite matices y condicionantes, y que se basa en el conocimiento necesariamente limitado que tengo sobre el asunto en cuestión. Nunca se me había ocurrido que esa forma de actuar puede estar, a veces, equivocada.

No sé si cambiaré mi forma de opinar, pero me lo pensaré dos veces antes de llamar dogmático a quien exprese sus ideas con demasiada firmeza.

Über bloggers Jeff Atwood and Joel Spolsky are joining forces to launch stackoverflow.com .

According to Jeff Atwood:

Stackoverflow is sort of like the anti-experts-exchange (minus the nausea-inducing sleaze and quasi-legal search engine gaming) meets wikipedia meets programming reddit. It is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.

According to Joel Spolsky:

We’re starting to build a programming Q&A site that’s free. Free to ask questions, free to answer questions, free to read, free to index, built with plain old HTML, no fake rot13 text on the home page, no scammy google-cloaking tactics, no salespeople, no JavaScript windows dropping down in front of the answer asking for $12.95 to go away. You can register if you want to collect karma and win valuable flair that will appear next to your name, but otherwise, it’s just free.

There is nothing there yet, apart from a podcast. But, with their combined talents and high profiles, it could be a great resource for software developers. I will be watching with interest.

Blog, Web Log, Talk, Express, Contribute, Help……..

Yes I will like to do all above. Also I always tried to start doing so. BUT. A big but always comes with the reasons like “No Time” or “something I will like to Blog has already been Blogged”.

Finally I have a new year resolution(after one month of new year) to Blog.

I suggest my shy friends who have much to say. Start Blogging, even if don’t have anything to blog or your language is weak.

Here’s something for you to start with by Jeff Atwood -How To Achieve Ultimate Blog Success In One Easy Step

Δ

Even in software development, where developers could spend all day for weeks coding within the confines of their rooms, human interaction is still critical. Here’s an excerpt from an interesting article from Jeff Atwood’s Coding Horror:

Bruce Eckel deftly identifies the root cause of all software development problems:

We are in a young business. Primitive, really — we don’t know much about what works, and we keep thinking we’ve found the silver bullet that solves all problems. As a result, we go through these multi-year boom and bust cycles as new ideas come in, take off, exceed their grasp, then run out of steam. But some ideas seem to have staying power. For example, a lot of the ideas in agile methodologies seem to be making some real impacts in productivity and quality. This is because they focus more on the issues of people working together and less on technologies.A man I’ve learned much from, Gerald Weinberg, wrote his first couple of books on the technology of programming. Then he switched, and wrote or coauthored 50 more on the process of programming, and he is most famous for saying “no matter what they tell you, it’s always a people problem.”

Usually the things that make or break a project are process and people issues. The way that you work on a day-to-day basis. Who your architects are, who your managers are, and who you are working with on the programming team. How you communicate, and most importantly how you solve process and people problems when they come up. The fastest way to get stuck is to think that it’s all about the technology and to believe that you can ram your way through the other things. Those other things are the most likely ones to stop you cold.

Bruce misremembers the actual quote; it’s “no matter what the problem is, it’s always a people problem.” But Bruce’s reformulation has a certain ineffable truthiness to it that is certainly in the spirit of Gerald Weinberg’s writing.

Let’s say I was tasked with determining whether your software project will fail. With the responses to these three questions in hand, I can tell you with almost utter certainty whether your project will fail:

1. How many lines of code will your team write?
2. What kind of software are you building?
3. Do you like your coworkers?

That last question isn’t a joke. I’m not kidding. Do you like the company of your teammates on a personal level? Do you respect your teammates professionally? If you were starting at another company, would you invite your coworkers along? Do you have spirited team discussions or knock-down, drag-out, last man standing filibuster team arguments? Are there any people on your team you’d “vote off the island” if you could?

It may sound trivial to focus on the people you work with over more tangible things like, say, the actual work, or the particular technology you’re using to do that work. But it isn’t. The people you choose to work with are the most accurate predictor of job satisfaction I’ve ever found. And job satisfaction, based on my work experience to date, correlates perfectly with success. I have never seen a happy, healthy, gelled, socially functional software development team fail. It’s a shame such teams are so rare.

As Weinberg said, it’s always a people problem. If you aren’t working with people you like, people you respect, people that challenge and inspire you– then why not? What’s stopping you?

Similar to the weakest link in the security chain, the person behind the PC is still the problem. However, in software development human interaction, when managed well, is as important as the human interaction necessary for any marketing work. Jeff Atwood is doing a great job in terms of publishing his articles online. Note that he makes it a point to write in less cryptic terms – comprehensible to people who do not have any formal IT training. He does not seem to treat the end user as THE problem, but more like a partner. Hence, he brings the discussion to a certain level that almost everybody can comprehend.

If this is how our policy makers, development planners, program managers, academics think and operate, maybe we’ll have less communication gap and better working relationship across sectors. Just a thought.

Aside: Hosted software would be something like Gmail, while installable software would be something like Outlook. WordPress.com is hosted software by Automattic, but it is also available at WordPress.org where you can download it and install it yourself where ever you want.

There are a few “internet rockstars” in programming circles, and most programmers who read blogs will have heard of Joel Spolsky (one of the few people who writes entertaining tech books) and 37signals (the guys who made Ruby on Rails and Basecamp). The guys at 37signals recently wrote a post about how they prefer creating web-based software that they host vs software that a user would have to download and install themselves because it is so much easier for the software developer. When you don’t have to release your software into the wild you have so many less things to worry about: different operating systems, memory performance, installation dependencies, hardware dependencies.

“You have to deal with endless operating environment variations that are out of your control. When something goes wrong it’s a lot harder to figure out why if you aren’t in control of the OS or the third party software or hardware that may be interfering with the install, upgrade, or general performance of your product. This is even more complicated with remote server installs when there may be different versions of Ruby, Rails, MYSQL, etc. at play.”

Joel looks at his stats and points out that if he didn’t provide installable software then he’d be out of business, because it accounts for 80% of his revenue compared to hosted software.  He also makes a great point that software that people are willing to buy is software that solves a gnarly problem, IE: it deals with complicated stuff. Any other kind of problem can be solved by free software because its uncomplicated enough that one guy in his mom’s basement can churn it out over a weekend.

“The one thing that so many of today’s cute startups have in common is that all they have is a simple little Ruby-on-Rails Ajax site that has no barriers to entry and doesn’t solve any gnarly problems. So many of these companies feel insubstantial and fluffy, because, out of necessity (the whole company is three kids and an iguana), they haven’t solved anything difficult yet. Until they do, they won’t be solving problems for people. People pay for solutions to their problems.”

But he then follows through with a great point that the gnarly problem that 37signals’ applications solve is the problem of design. 37signals might be building fluffy Ruby-on-Rails Ajax sites, but that’s beside the point of the problem they’re really solving: how to design a great looking user experience that makes people happy.

I think this draws a great parallel to what’s wrong with free software: it’s created to scratch a certain itch, and that’s usually all it does. Compelling user interface? Joy to use? Nope, it solves the original programmer’s problem and that’s about it. And before you get all uppity that I’m attacking open source software, let me clarify that I’m talking about the open source software I create.

The problem is two-fold: I have a natural tendency to over-complicate things and I have trouble sharing the customer’s pain (stepping away from the code, and seeing how a stranger would view the end result). Jeff “Metal” Atwood asks “When was the last time you even met a customer, much less tried to talk to them about a problem they’re having with your website or software?”

This hit me last week when I sat down with another engineer to show him an internal tool I was building for him. He started poking a usage case that confused him. It wasn’t in the spec, and it didn’t follow the way he thought of the flow. It was an artifact of the internal data structures I was using that I was exposing to the user. This happens too often. It’s the opposite of opinionated software [1]: pushing the decision making on to the user. [2]

Of course, writing open source software has its benefits because quite often there’s no barrier between you and the people who are using your software other than computer screens. You are your own quality assurance, and you are your own customer service. You have to explain to the users why they should install your software, you have to deal with the installation headaches your platform choice created, you have to explain any complexities with how to use it, and you have to help them when problems occur.

My open source software might suck, but its helping me explore the solution to a gnarly problem: how to solve problems in a way that is easy for other people to use.

Related Posts

• Getting to Simple – Engineers Have No Idea How Normal Human Beings Interact With Their Environments
• The Missing Curriculum for Programmers and High Tech Workers
• How to be a Programmer with 10 Simple Books

Footnotes

1 – There’s an interested essay to be written comparing opinionated software to considerate software.

2 – This programming talk might bore you, but the problem of simplicity in design is cross-discipline and applies to any blogger.

I recently decided to start a blog. I am a software developer about a year and a half out of college, and thankfully am one of the lucky ones who has managed to be gainfully employed for a year. I frequently read Jeff Atwood’s blog Coding Horror. I could not find the actual post, but I remember he gave advice for junior level people like myself, and one piece of that was to start a blog. I have been playing with the idea for a little while now and I finally decided to buckle down and give it a shot.

So here it goes…