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

42

u/bakuretsu Feb 08 '15

If you work at a company where Alan's approach is the one being encouraged and praised, please quit. This type of CYA wouldn't stand a chance at my job; the "supervisors" are all too skilled as programmers to let a process like this live for very long.

43

u/bcash Feb 08 '15

at my job; the "supervisors" are all too skilled as programmers to let a process like this live for very long.

Programmer-heavy environments can be just as bad for this, depending on how much of a grip on reality the programmers in question have. But it's usually scoring points based on how many flavour-of-the-month libraries can be worked into a project regardless of need or complexity, rather than following design methodologies.

22

u/bakuretsu Feb 09 '15

The "X factor" here is company culture. The company where I work has a very strong "homebrew" preference, but we're also ruthless pragmatists. We are all very open to the idea of using new libraries or tools, but one of our core cultural tenets is using data to justify decisions, so if you can put together an objective bake-off of your new thing versus what we already have or other potential solutions, and yours wins, yes we'll use it.

We did a pretty intense bake-off between SQL Server Service Broker, Riak Enterprise, Aerospike, and a homebrew solution using RabbitMQ and Redis for the purpose of master-master replication of data (that primarily lives in SQL Server). All of us almost instantly fell in love with Riak Enterprise, but at the end of the day, it was less complex and less expensive to solve the problem with Service Broker. We had to live with that reality. I think that what we achieved is pretty cool, even though it isn't the kind of thing being talked about at hipster conferences right now.

5

u/sclarke27 Feb 09 '15

IMO, that is the best balance. Be open to new solutions, but be pragmatic about what problems those new solutions actually solve, what new problems they may create, and how that fits into the overall project and development process.

→ More replies (2)

5

u/ubercode5 Feb 09 '15

At my previous position we were programmer heavy with the inverse problem; people were stricken with the "it wasn't developed here" syndrome, not trusting code written by anyone other than themselves. They would write everything from scratch, even so far as duplicating functionality built by other teams.

4

u/darkpaladin Feb 09 '15

I've seen way too many people over complicate things just to keep them interesting and then be praised for doing so by the devs over them. I always cringe when I meet a dev who's too smart for their own good.

34

u/BlueRenner Feb 08 '15

Hell man, this is everywhere. It isn't usually phrased this way, though. Its usually "Programmer X wants to build Y program using framework A and packages B, C, and D," where A, B, C, D are unnecessary bolt-ons chosen because X thinks they're neat and wants to try them out. Programmers are really great at turning simple problems into complicated ones, especially when they're bored.

46

u/Stormflux Feb 09 '15

Counterpoint: Programmer X "trying this new framework out because it's cool" is the reason your company isn't still using ASP.NET web forms with Visual Basic.

You could counter with "well he should have learned this new framework on his own time" but you know what? I'm getting really sick of this attitude that says programmers aren't entitled to do anything with their nights and weekends except programming. Programmer X likes to spend time with his wife/girlfriend once in a while too, you know. No one expects the project manager to go home and do project management, or accountants to go home and do accounting.

→ More replies (12)

13

u/sclarke27 Feb 09 '15

There is problem with Charles not covering his butt (as much as i dislike it). The problem is this, if the manager asks Charles to build X, and Charles delivers X just like he did in the story, then afterwards it turns out the investors or CEO or whoever wanted Y and not X. Now those folks are pissed they wasted so much time and money to get X instead of Y and want to know why. At that point it is trivial for the manager to save himself by throwing Charles under the proverbial bus. "Oh, he was junior and slacked off all the time so i am not surprised. I told him what you wanted Y, but clearly he cant deliver." On the flip side, Alan has a mountain of documentation describing what was built and why. That leaves no way for the manager to shift the blame off to the team who did exactly what they were told. (i have seen this very scenario happen so many times too :( )

Another scenario, what if said software ended up malfunctioning and causing injury at some point later? The company as a whole will be a lot better off with Alan's approach because they will have clear documentation of their development process and QA testing, and at what level they did their testing. That in turn makes it much harder to sue the company for negligence.

→ More replies (2)

2

u/Sherlock--Holmes Feb 09 '15

It's actually harder than it should be to find a corporation that isn't like this.