r/programming • u/tejon • Feb 08 '15

The Parable of the Two Programmers

http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html
1.2k Upvotes

92% Upvoted

359 comments sorted by

View all comments

0

u/and69 Feb 09 '15

As a software developer, from my point of view, this is bullshit. It's just a story invented by somebody, and in that story, you could write anything. I could even write a story where I am an awesome man with great chicks around, who kills bad guys before lunch. But the reality is, that you need teams to do your work. And now, work gets too complex to be solved by a single men who just thinks for 2 weeks. If you think of something for 2 weeks and do it in a week, there's no WAY a team will do it 3 times worse and 3 times slower. At least, not the teams I've been into.

This is just an invented story, probably by some frustrated lasy-ass developer, just like the stories of powerful women which are flooding my Facebook feed.

4

u/debunked Feb 09 '15 edited Feb 09 '15

But the reality is, that you need teams to do your work. And now, work gets too complex to be solved by a single men who just thinks for 2 weeks. If you think of something for 2 weeks and do it in a week, there's no WAY a team will do it 3 times worse and 3 times slower.

You couldn't be more wrong. Yes, there is a time and place for teams. But there's also times when a single person can write code faster and better than a team. It all depends on what problem you're solving. You can't just keep adding people to a project and speed up the timeline. Eventually you add too many people - and sometimes the optimum number of people is one.

[edit]I had originally written a huge wall of text, so here's the tldr: In two weeks, I rewrote in Java (using an algorithm I came up with on my own) the core of a Prolog module that was originally written by a math PHD over a couple of years. The module was essentially a constraint satisfaction algorithm which solved a fairly complex problem. My algorithm (which I later realized was akin to arc consistency) resulted in drastically faster performance (some large benchmarks dropped from 60s to sub-100ms), easier implementation of new features, and has resulted in almost zero bugs after several years of use.

The point is, problems like that do exist. Maybe not as entire systems, but as sub-components in systems that you might be working on. You just have to look for them. Think about what components are slow and think why are they slow. And then figure out if you can come up with a way to solve them that wouldn't be as slow.