Why I love solo programming (and why I hated working for Pivotal)
mwilden.blogspot.com
mwilden.blogspot.com
For me it boils down to being able to fit the entire codebase into your head, or at the very least have it all written in your own voice. Reading code and packing it into your brain is the hardest part of programming, so having it all written in your own familiar style makes it really easy to get back up to speed on any bit of the project, even if you haven't visited it in a while.
Having even one other developer in there making changes can throw you out of speed-reading mode and make you stop and figure out what the other guy was thinking. That slows you down, and slowing down opens the door to distraction, which leads to bad things.
It gets really good when you're working by yourself on a project for which you're providing the direction. That removes the last roadblock from productivity, the "boss requested change".
Nothing like it, if you're lucky enough to be blazing the trail.
The problem is for engineers who come in after you've left for greener pastures. If you don't document your style, design decisions, and over-all development process you're leaving behind a legacy... of miserable programmers who will make up stories about how awful you must have been.
The engineer in question might be yourself, six months or a year later, and you will have completely forgotten what you were doing back then.
It might not work for everyone, of course, but it is probably beneficial for 90% of working programmers. So do not use this as an excuse to not try pairing (or working in larger teams, others' code etc.) with an open mind.
You are always expendable and can be shoved around like an animal, especially if you are a true team player that always nods and smile are "the best" to pair up with.
In fact, the cowboy programmers still rule the programming session when you pair up with them and they can easily take up most part of the day arguing small uninteristing details until they get it their way making the software theirs - not the team.
Your first paragraph is more interesting. How does the fact that someone else also contributed diminish pride in craftsmanship? Presumably it's the program you're proud of, so if the program comes out better, isn't that reason to be prouder? (If the program comes out worse, that's a problem.) Personally, it would drive me crazy to work with people who were constantly worrying about who contributed what. Software development is hard enough as it is. We can't afford to waste valuable cycles on that kind of thing.
My experience has been that the solitary-genius fantasy is the calling card of an immature programmer and is purely something to get over. (Just so it's clear, I'm not drawing this conclusion about you, nor about the OP.)
It may be true that co-programming makes crappy teams worse, but it also makes great teams better. As far as I'm concerned there's nothing better than a small team of smart people hammering on a hard problem together. But there's no question that it forces team dynamics into the open.
You missed "may" before "makes" in the second part of your statement.
One thing where I had good experiences regarding paired work was serious bug hunts. There, the most important part was the discussion and the constant back-and-forth of ideas was actually productive.
This has been pretty hard algorithmic work, though. No fleshing out hundreds of lines per hour.
I will admit, though, that for a while we jokingly called it 'peer programming' because you were just peering over someone's shoulder. We had a cowboy coder that taught us a LOT of stuff in the short time he was here and 'peer programming' was a large part of that. His time here was disruptive, but I think the whole team is a lot more productive thanks to his short employment. (And his disruptions were mostly him trying to convince everyone to do things a better way.)
Eliminating bugs up front is like asking human beings to be perfect.
In other words, good luck with that.
Its like video gaming - either you can run circles around them, or they around you. Its really rare to find a good match.
Now compare with programming - its wellknown that skills in this arena range from 1 to 1,000,000. The chances of a good match nearly disappear.
Unless the skill level/experience of the two match pretty darn well, its a dead loss in productivity.
The best way I can describe it is that my "personal zone" for people not in my immediate family is about arms-length. If you're close enough to touch me, I'm uncomfortable. If we're sitting shoulder to shoulder at a keyboard, I'm so uncomfortable that I can't work.
This gave me goosebumps. If there was a way I could work this into my current office environment, I'd be in heaven. I love looking at fish, reptiles, insects etc...
I guess I could always buy a fish tank and plonk it down beside me.
From a team perspective, people can work together when they need to, or run off to do research on their own and so on. It is an open experience where the Team figures out on their own how to best work together.
In pair programming, developers are FORCED to work a specific way. And that might not be the best way for that developer. I think Mark would have had a much more enjoyable experience in a team centric environment where each person is able to add to the team in the way they feel most comfortable.
Agile is about self managed cross-functional teams. As soon as upper management forces a team to work in a specific way, that self managed aspect disappears.
I do understand all of the advantages of paired programming but think you can get those and a lot more focusing on teamwork instead of pair work.
My two cents.
Likewise TDD (famously: http://www.infoq.com/news/2007/05/tdd-sudoku), Agile, etc. None of these things is a panacea, but they can be very effective if thoughtfully applied.
When pairing I never can get into that state because I keep getting interrupted with "name that method x", "move that method before that method", "refactor now". It really breaks my focus.
I find it useful when tracking obscure bugs, where you can bounce ideas off of someone and basically nail the problem faster.
By focusing on keeping the driver in flow you begin to appreciate when it's better to shut up and let them get on with writing the code, accepting that people have different coding styles is important here. You can then use your attention to either help out when they get stuck or maybe to tell them what the next test should be.
(This is what they'd say, at least. I like pairing, but I don't know if I'd be comfortable making an absolutist statement like that.)
(Our typical project scope is 2 people, 2 weeks; small projects 1x1/1x2, bigger projects tend to add weeks and not people).
Do you think your clients will pay more than they currently are for quality software that meets their needs?
If so, just start charging more. Make up whatever story you want about why you're charging more.
If you don't think you're producing quality software that meets your client's needs, but you think your clients would pay more for such software, then take whatever steps necessary to make better software and then start charging more.
My language was vague, but I didn't mean to imply that you charge current clients more, just charge new clients more.
It struck me as odd that you'd have to tie any price increase to an increase in your costs. If Lexus wants to start charing more for their cars they don't need to think of ways to use more steel. They just charge more and justify it however their marketers think is best.
If you sell developer-hours instead of products why not just charge more per developer-hour?
"Oh, you want this application tested? Well, first you want a 2-person, 2-week threat modeling project where we give you a report on your attack surface, then you want a 3-person 4-week testing project, and if that turns anything up, you'll absolutely want a 1-person 3-month deep code review."
Here's an example from web design:
"Oh, you want a website for your new product? Well, first you'll want us to study the market for a week. Then you'll want a wireframing project so we can agree on what we're going to build; that's going to take 2 weeks. Then we'll spend 2 weeks on design and get you some comps to look at; if you want changes, we can do another week of that. Oh, you want HTML? Sure, we'll add on 3 weeks of coding."
I'm sure that some witness to software consulting could provide you with a story that fits this thread more directly.
Why not do X or why not do Y? Obviously, you're not a golfer. They do it to make money, without alerting the client to the fact that they're simply ratcheting up the dollar cost of the whole project.
I can see why it's unethical to deceive the client about what components they will actually end up needing. I can see how you'd make money by luring clients in with cheap prices up-front then once they are locked-in charging more for the things they will inevitably need but didn't pay for already.
How does that relate to how you, as an ethical consultant, could raise your prices without raising your costs.
Are you saying that the only way you could raise your prices without raising your costs would be through scope abuse?
> And as far as pairing is concerned, I know for a fact that I'm not as productive as when I pair-programmed at Pivotal. We got some amazing results, just chugging through the feature list.
Also, pairing can be both a productivity enhancer and a lever used by project managers and salespeople to increase project scope.
Disclaimer: I work there as a consultant every now and then
And sufficiency is at the core of what makes software development fun and productive: a sufficient number of eyes on the code, a sufficient issue tracking app (and/or other collaborative apps) and sufficient amount of automated test coverage is often all you need.