thedwick

They say the first thing to drop on the floor when a team tries any Agile methodology is pairing. The opposing arguments tend to go like this:

Old-School Manager: “Why is everybody going so slow? Why is it that I’m using twice as many people to get half the work done?”

Agile Cheerleader: “You have to consider what else you’re gaining. By pairing, you will get higher quality code with fewer defects. You’ll also increase adherence to team standards because pairing is like real-time code review. And on top of all that, you’re reducing key-man risk by spreading knowledge. So in reality, over the long haul your project is going to be much faster.”

Old-School Manager: “Ok, yeah I guess that makes sense.”

But odds are, the first time the project misses a high-level milestone, or otherwise starts to feel behind to the Old-School Manager, pairing will go right out the door. Either as an edict from the manger, or (I think more likely) as a disease that starts to catch on among the developers. As pressure increases to get more work done, each will feel like “golly, if I’m pairing with Joe to get his cards done, then I’m not getting my cards done. How does that make me look?”

The problem is that even though most rational people, when thinking rationally, will see that pairing increases the throughput of a project, in a local (ie. developer-by-developer) sense it feels slower. And people are emotional beings so feelings count for a lot.

When I’m interviewing people, I spend probably 70% of the interview trying to probe how good they are at recognizing and weighing trade-offs. Sure, I ask technical questions like “describe an interesting design pattern” or “what’s the difference between an array and a linked list”, but most of those questions are immediately followed by “…and what’s the trade-off?” Candidates probably think I sound like a broken record.

But there’s a reason I put so much emphasis into probing trade-offs instead of their knowledge of Transact-SQL syntax. There are several, actually.

First, if someone knows a technology really well, then they understand that technology’s trade-offs.

Second, software engineering involves constantly deciding among many trade-offs and that’s a lot of what makes it so hard. If it weren’t so hard, robots could do it.

Third, people who don’t consciously make trade-offs tend to waffle around instead of sticking by their decisions.

So people without a keen sense of trade-off end up blundering their way through software engineering making trade-offs they aren’t even aware of in languages they barely understand. And they constantly change their mind. It’s as if all that instruction they had in CS 46a about trading off memory usage vs. CPU usage evaporated right after the final exam.

Successful engineers and managers tend to understand that no matter what decision they make, there’s always a downside somewhere. The key is to be aware of that downside and consciously accept it. Then, later, when that downside becomes apparent to others and you’re facing criticism for it you can confidently explain why you choose it anyway and what benefits you will reap (or already have reaped) because of your choice.

I would like to see a new breed of programming language. I’ve been seeing lots of talk lately about functional languages like Lisp, and it’s been a good reminder that the currently popular way (ie. object oriented languages) isn’t necessarily the only or even the best way.

I remember being so excited by Prolog the first time I learned it in college. Using it felt like I was telling the computer: “here’s what I want, now go figure out how to do it.” I remember thinking that was the coolest thing in the world. So why have I never used it in reality-land? Well, at the time you couldn’t build a GUI out of it, or interface it with anything useful, and if you started getting into useful and interesting problem spaces, you ended up having to figure out how to make Prolog do what you want, rather than tell it what you want and let it figure out how to do it.

So there’s that.

From another angle, I’ll often times have a problem to solve where I just care that the solution my software comes up with is “close enough.” That’s because I live in reality-land where the Real Number Line is real and there are an infinity of points between 1 (true) and 0 (false). But computers don’t live there. They can only pretend to live there if we give them algorithms and approximations for filtering an infinity of possibilities into a one or a zero.

So smash those two wants together and you get what I’m thinking of as a Continuum Language. At this point this is mostly a 10%-formed idea that started brewing in my head a couple of days ago. But here’s what I have so far…

Start with a program like this (obviously very high level):
1-Make money;
2-Sell widgets;
3-Where 1 and 2 conflict, 1 is more important;

Or the next step, like this:
1-Make money;
2-Sell widgets;
3-Where 1 and 2 conflict, 1 is 3 times more important than 2;

If you’ve only got 2 variables, this program isn’t very interesting. But if you’ve got many more, it’s much more interesting.

How do I boil that down to its most primitive concepts to make a language?

Something else I’ve also always wanted to say easily in code:
1-Log this message 30% of the time you get to this line
2-This input field should mostly look like (510) 555-1212.
3-Do this very expensive and usually unnecessary validation step with %40 probability.

Anyway, a thought still brewing. Hopefully I’ll come up with something more concrete over time.