What kind of programming method do you prefer? Success vs. Freedom

Would you prefer to have total complete freedom over all of your development techniques, or would you rather follow a safer more boring approach that has a significantly better chance of working in the end? Hacker vs Engineer? Painter vs Electrician?

From stackoverflow

• The "freedom or nothing" attitude is juvenile and annoying, the real world doesn't work this way.

  Give me established process.

  Steve Jessop : Agreed: if the process works, be a professional and use it. In particular, if the safer more boring approach is known to work better, why wouldn't you freely choose it? Failure is one of the few things even more tedious than just writing the frickin' documentation.

  Ken Gentle : +1: One could certainly argue that having process for the mundane decisions leaves one the ability/time to focus on the problem to solve, being creative where it adds the most value.

• Economist. If it makes me money and isn't unethical, I'm all for it.

  Mostlyharmless : The "Economist" part implies "unethical or not, i dont give a damn"

  Tim : Um, no. unethical is not economical in the long run...

  Steve Jessop : Tell that to Rupert Murdoch.

  RoadWarrior : Unethical is orthogonal to economic.

• Personally, I prefer the freedom to try new ideas, new techiques, new processes, but I think it should be self-regulating. That is, I think the the techniques, processes, etc. need to prove themselves beneficial. Demanding freedom of personal expression in a team environment is probably not a good way to build the team, but I think the team should be open to improving through new ideas. Once a process/technique has been adopted by the team, though, it would be counterproductive to continue to insist on your own way (even if better) if the team doesn't see it the same way as you.

• Depends on if you are smart.

  If you are smart, then freedom. You'll make your own success.

  But the problem is, nobody can honestly tell if they themselves are smart.

  tvanfosson : Even smart people can be really dumb at times.

  Bill K : -1 for the vote for freedom, +1 for the nobody can tell if they are smart :)

• Working in larger groups taught be the values of established, documented processes.

  As long as you're working in a small team (2-4 people) where you know everyone well and you all have a common goal, you can probably work great without having a defined process.

  As soon as 10 people have to cooperate on something, you'll want at least some basic rules, so that everyone is on the same side.

  When you're doing a project with 100 people, then you will get nowhere, unless you have very specific rules and a well-defined process.

  Personally I'd prefer if I could do whatever I like and everyone else worked according to a strict process ;-)

• There are different aspects to freedom. When you are restricted from changing half the codebase because it's already "tested" (even if it is coded poorly), I'd say that's a case where you need freedom, but I don't think you're talking about that.

  Hacker style freedom, to use whatever tools are necessary to solve the problem, and solving the problem as a primary goal just terrifies me these days.

  I've never seen code that didn't need debugging/fixing at some point, and the debugging/fixing always seems to take more time then the initial coding did, so making that first round of debugging/maintenance/enhancement as easy as possible needs to be your primary goal.

  This conflicts with "Freedom" because "Freedom" often implies you are able to choose mechanisms that will take other people longer to deal with--and it's most likely other people that will be doing that first round of maintenance.

  Steve Jessop : "it's most likely other people that will be doing that first round of maintenance.". My company-before-last had a simple way to solve that. Once you wrote something, the only way you could *ever* be truly free of maintaining it was if you left...

• I don;t think the freedom vs boring is valid. A defined lightweight process that is also flexible is certainly doable. Until someone can show me that they are adept at development I will probably not allow so much freedom.

  Following a stodgy inelastic process can be detrimental as well.

  Lots of common sense is needed, but it is a difficult thing and this all varies between developers and organizations. There is no one size fits all.

• What if you put your angst for freedom into being creative in new project areas instead of inventing Yet Another Development Process?

• I like to get things done. This means using established development tools and a reasonable process, while being creative in what I do within that process. The greatest poetry in the English language was written to strict meter and rhyme rules, and seems none the less creative for it.

• This is not a valid question. You can exercise your freedom to follow a process, or you can exercise your freedom not to follow a process. Whether you follow a process or not, you still have freedom.

• "Success vs. Freedom" implies that if you are free to make decisions the program will not be a success.

  I think you really have to rethink this. In my experience, Developers need to be FREE to choose the best method of implementation, if it is better after review than the "tried and tested" methods then it will be kept and used by the rest of the team. But they still need to ensure that the code they write is SUCCESSful in accomplishing the tasks they are meant to carry out.

• "Freedom" in this case just seems like an emotionally positive word tied to an unpleasant concept. It could just as easily be replaced by "stubbornness" or "carelessness." Even the question itself is framed as "what I want to do" versus "what's likely to work."

  Of course, anyone is free to pursue any path they choose. But I personally wouldn't devote a moment of my life to something that I didn't care about, and if I did care about it I would do everything I could to maximize it's chances of succeeding. I don't see that as "restrictive" at all.

• It's a false dichotomy. Imposed process doesn't correlate with success. For example, in the phone companies, there is an enormous amount of process imposed on software developers (naive reading of 'waterfall' development) with the effect that much time is wasted writing detailed design documents, then when the software is delivered the customers suddenly discover that what they asked for isn't what they wanted. At that point resources are almost exhausted and everybody loses. Imposed process kills projects.

  On the other hand, when Amitabh Srivastava imposed some basic analysis and testing requirements on the Windows team, bug rates went down, and at least among my friends at Microsoft, productivity and morale went up. I assume something similar happened on the KDE project when they started requiring everybody to use valgrind. Suddenly, no more memory errors and baffling core dumps.

  In general I think it is more successful to impose useful tools than to impose processes. Evidence for or against the utility of a tool can accumulate fairly quickly. The only 'process' that I've seen is consistently successful is that more than one pair of eyes should see the code. The mechanism by which this viewing is achieved doesn't matter.

  Freedom for developers is a different question entirely. I'm lucky in that I have a job where I have nearly complete freedom to choose everything about my development environment. (Example: I work in a Red Hat shop, but I had budget to buy a computer and install Debian.) Since I have over 20 years' continuous software-development experience, I can usually make pretty good choices about what languages and tools to use. But the flip side of that is that I can be reasonably productive in any language or environment. Using perl or C++ might slow me down by a factor of 2 or 3, and using Lua or Haskell will speed me up for certain problems, but I'll get there in the end.

  But I've worked with other developers who have a very limited comfort zone as far as languages and tools go, and who will cheerfully choose a very wrong tool for the job if given the freedom to do so. I was once asked as a consultant to try to help a group speed up a compiler that was taking 24 hours to compile small programs. It turns out that the people who had written it were expert-system people and they had written a compiler using a rule-based inference engine. They got it to work, but it was the wrong technology for the job.

  I've also seen that constraining a developer to particular environment or language is no guarantee of success. I consider myself a very bad perl programmer; I basically treat perl like awk on steroids. I'm a complete idiot. And yet I've had to deal with perl code written by others that was far worse than anything I could write just because they had never learned to think about problems or about how to organize code.

  I think I'd better stop ranting now.

  Mike Dunlavey : +1 This is boot-soldier's wisdom.

• The question of whether to stick with conventional wisdom or "think outside the box" has been around forever in most disciplines, not just programming. I think it has to be decided case-by-case.

  I've been to conferences where the most popular papers seem to be in-depth analyses of things-as-they-are. Not unlike SO, where popular ideas are up-voted.

  This would be OK if there were not serious problems in the field. Much (if not most) software is still way too bloated (IMHO) and suffers chronic performance problems. Things-as-they-are are stable, but are they good enough?

  I think we need new ideas, and those will necessarily be unpopular, unconventional, and risky, for a while.

  I'm glad that SO permits unconventional ideas to be discussed, not as flames, but as ways to question the status quo.

• Doesn't it also depend on what you're going to build in the end?

  These guys follow established processes : http://www.fastcompany.com/magazine/06/writestuff.html