-
Currently Reading
How Reddit Will (Maybe) Save Software Development
Posted on May 12, 2008
Filed Under Programming, Software Development |
Or, This Started as a Diatribe About Bad Programming Books, and Turned Into Beating a Dead Horse.
Decades after The Mythical Man Month 
Edit: As pointed out by Greg Molyneux , the pyramids were not built by slaves . Was EVERYTHING I learned in history class in middle school a lie?
Programming failures are due to a lack of rigor at all levels. The requirements suck, so the design sucks, so the interaction between modules suck. These problems will continue to persist until development practices assume that the developer and designers are making mistakes, and does everything possible to correct the mistakes early. This will be done, not by a slick methodology from a book, but rather a karma-based social programming application.
To strengthen my case, I want to look first at mathematics.
Why Does Math Work?
Mathematics, despite its difficulty, continues its inexorable advance. Theorems Conjectures that have withstood the test of time are falling, one by one; just ask Fermat and Poincaré . New ground is constantly blazed, and even tired subjects– such as number theory– are finding new applications and new life.
First, let’s get the obvious difference out of the way. Mathematics is largely a theoretical field. Sure, we can often apply it to the real world, but where’s the fun in that? The goal is not to produce products for ordinary people, but rather to further mathematics as a subject.
Also only those who are fully interested in mathematics are mathematicians. This does not hold true for software development, as trade programmers exist. I’ve met them. These programmers simply bang out code day to day as a living, and are not thoroughly passionate about programming.
Now, let’s see what math does right:
Excellent Peer Review System: Mathematics is advanced through proofs. These proofs are carefully perused by other mathematicians. Even better, there is an incentive to find mistakes: when an error is discovered in a published paper, the discoverer can write a paper on the subject. This ups the yearly publication count by 1, making the mathematician seem more valuable. It’s like karma!
At the end of the day, the effect is clear. The only mathematics that survives has seen a thousand eyes, and subtle flaws are discovered in due time. For example, Bertrand Russell discovered a contradiction in set theory near the turn of the century. This caused set theory to be ripped up from the floorboards and be rebuilt on top of new assumptions that did not fall victim to this same flaws. The paradox is now known, unsurprisingly, as Russell’s Paradox .
Open source software also has this same advantage of many eyes, but open source software also does not do everything for everybody. Yet.
So How Can We Fix Software Engineering?
In one sense, we may not be able to. People are not usually programming for a decade before they enter the field, so it turns out that some people were just never meant to be programmers, and it is too late!
Other people will always code without "reading the manual" on their coding methodology. They will use the waterfall method. They will take eXtreme Programming as a blanket excuse to code without thinking. They will adopt the Rational Unified Process, but forget about that testing thing because it takes too much time. It could be impossible for collectives of the uninformed to produce good work.
The best, on the other hand, do not need to be regulated. They know better than anybody else about their own personal shortcomings (whether they realize it or not), and they use them to their own advantage. They know they are likely to make breaking changes to their own code, so they use version control. They know that they are going to write bugs, so they do everything they can to automate their finding. They already have a library of old code that is tested and works, so they can finish projects faster.
So to fix development for the rest of us, we need to approach software engineering like we would approach mathematics: with rigor. We need to treat it as if it is an incredibly difficult subject. We need a plan of attack, and there needs to be an excellent review system. However, I strongly suspect that most developers will not willingly go along with the rigor associated with, well, rigor. They may give it good lip service, but when it comes time to write the 60th test case for their physics simulation, they just might start cutting a corner or two. So what will the next programming methodology have to do better? One of the following:
- Simulate rigor from the unrigorous.
- Encourage rigor.
The Next Big Thing in software engineering methodologies may even do both. How could it accomplish this? Incentive! There has to be an incentive for programmers to do rigorous work, which is why I think that the Next Big Thing will come, not with a book, but with a slick collaboration GUI that encourages/rewards rigorous activities with karma. If Reddit has taught me anything, it is that people will do anything for something as worthless as a karma point. Of course, this would need more serious study before anything was actually produced, but we’re talking theoretically at this point.
What The GUI Will Need
The program would best be served by a karma system, similar to Reddit. The program will need to keep track of (and reward) the activities most associated with rigorous programming.
I haven’t really worked out the details (being elbow-deep in another project), and there are many details to work out. Ideally, the GUI will be able to reward good design, good requirements, good code, and good tests.
I just want to give you a quick example of how the program can work: rewarding unit tests. When tests are coded well, they tell you when things break, and they tell you when things are (likely) working. It is generally well-agreed that programmers should write unit tests for their code. Despite all of this, the actual writing often fall by the wayside at the 50th unit test for your extremely boring file parsing function.
The program should reward you points for the number of unit tests you write for anybody’s code. Other programmers are human, and can often simply forget to perform these measures. They could even document the areas that still need work if they are fatigued by the process. They shouldn’t be penalized for something that should easily be added by another programmer. After all, if the function that they wrote is any good, they will be rewarded with karma for the function.
Obviously, this can be gamed. You can simply write 500 unit tests for the "add()" function written by another programmer’s class. But not when the karma system comes into play! If other developers find that your unit test additions are worthless, they can downmod the useless unit tests, and they can flag you as abusive.
Why won’t the developers spend all of their time writing unit tests instead of adding to the development effort? It can be claimed that if they are adding the unit tests and getting upmodded that they are contributing to the development effort, but I will not dodge the question.
Why will they not game the system? At the end of the day, they have a manager, usually in their same office. The managers will be able to see who is abusing the system, who is getting the most downmodded votes, and will be able to read comments and get explanations from their team. They will be able to walk down the hall and say, "Hey, dummy! Write the binary parsing utility you’re assigned and quit spamming unit tests!"
This system has the benefit that, over the long haul, the manager gets to see who has contributed the most to the project, who has the most controversial changes, and who has contributed the least. They will get to see the comments that other developers have left, and they will get to see who is not fitting into the team.
Why Am I Telling You Instead of Making It Myself?
There are a few reasons.
- I’m sick and tired of using bad software.
- It will never actually work in practice for a lot of teams.
I will use this project to learn Ruby + Ruby on Rails… after the few big projects on The List already, but if someone else wants to hack up their own version, awesome! I’d like to see what is done with it.
Why will it not work in practice? Because politics, unfortunately, plays into programming decisions in some companies. As an intern, I was shocked to find out that this was true. It could be hard to give the thumbs-down to someone’s code on a Friday afternoon at 4:00 when you know that in a month, they will be your manager.
Not only that, but the workplace is not like the internet. When you flame somebody within the office, they could theoretically come to your cubicle and napalm you in the face. Not pretty.
The Reddit Programming System can only really work if you have a team that understands that everyone makes mistakes, and to just be an adult when someone corrects you. I believe that it can help small-to-medium sized teams, but the teams that would do well with the Reddit Programming System may already be the teams that are doing well with other methodologies.
I have no reason to suspect that it will help teams that aren’t performing.
Popularity: 16% [?]
Comments
10 Responses to “How Reddit Will (Maybe) Save Software Development”
Leave a Reply
In a way this is what the CPAN kwalitee ( http://cpants.perl.org/kwalitee.html) is aimed at. Of course it is for now rather primitive - but there is quite a bit of brainstorming in the Perl community on how to improve it.
There is a plug-in for Hudson that does something similar (although without the modding up and down):
http://hudson.gotdns.com/wiki/display/HUDSON/The+Continuous+Integration+Game+plugin
“…projects are still failing at an alarming rate.”
“Programming failures are due to a lack of rigor at all levels”
“but if someone else wants to hack up their own version, awesome!”
Ha ha.
@Bob:
I wondered if someone was going to catch that!
Hey Jake, great article, I agree with you on the Truth about Software Engineering:
http://softwareindustrialization.com/TheTruthAboutSoftwareEngineering.aspx
However, I disagree with your approach. Write more unit tests? This is after the fact that the software has already been written – it’s too late and a) it has already cost way too much to get there, as you have already pointed out and b) the unit tests may prove (likely) that the software was not designed correctly in the first place and has to be rewritten, again at an exorbitant amount (see a).
The key word I believe is design. And if you know about Jack Reeves and the source code is the design belief, then you know in reality, our world of software engineering suffers from no way to specify a software design and prove the software design works, before a single line of code has been written. I believe that is the right problem to be solving as has been done in other “engineering disciplines.
Cheers!
@Mitch:
I tried to hint at this (and apparently didn’t state the idea clear enough), but design would be another thing that this system could handle.. though design tends to be more of an abstract concept. I don’t immediately see how to peer-review sections of design in the general case, but I’ll certainly think about it.
When I saw you talking about Reddit and peer-review, I thought you were going to propose that programmers post their code in a Reddit-like forum, subject to votes and comments. The problem would be getting people to actually rigorously review the code. A lot of people comment and vote on things on Reddit without carefully reading the article or thinking about the subject. Reading and understanding code is more difficult than reading and understanding most articles.
I agree with much of the setup, not the conclusion. I agree that a social methodology of *design* is needed. The software industry is immature… similar to when the auto industry made the model-T Ford (it could be argued we are earlier than that… after all the Model-T was reliable, cheap, and produced efficiently.) My solution is to create a social requirements engineering system (this would also supersede bug dbs… since a bug is merely an anti-requirement.) I would integrate this requirement system directly with the testing system (could be unit tests or other types.) I’d call this “requirement verification”. This would make the “big triangle” of design-implement-test an actual triangle! Today, at software companies I’ve worked at the triangle’s sides are only vaguely related/connected. I bought the domain “OpenRequirements.org” hoping to advance this idea… if anybody wants to work on it with me please get in touch. I do a lot of CAD design (I create CAD software… IntelliCAD.) Note that blueprint-style design is actually a thousands of years old practice. The software industry has no analogous design methodology. We are at the phase where we construct a wooden Indian from toothpicks, glue and chisels (and we stop when we have a wooden Indian or we run out of time.) It should not be surprising that our end-products are of such low-quality, given this methodology. The keys to improving our design capacity are:
- Design captures requirements adequately. Social “marketplace of ideas” methods ensure this.
- Design is verifiable, and verified (integrated testing.) This is like having “machine readable specifications”
“Theorems that have withstood the test of time are falling, one by one; just ask Fermat and Poincaré.”
You mean “conjectures”, or “open problems” rather than “theorems”. Theorems are the end-product of mathematics. Fermat’s Last Theorem wasn’t actually *known* to be a theorem until a proof was found - until then it was a conjecture.
Ooooh there are flames in these here comments!!! Lol that’s sadly one of the best compliments the internet can give!
Seriously thought provoking article though. Sadly I’m too fried to pop off a quality comment but an enjoyable read none the less.