Which programming method do you prefer? Success versus freedom

Depends if you are smart.

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

But the problem is, no one can honestly say if they are really smart.

I don't think freedom and boredom are real. A certain easy process that is flexible as well is certainly doable. Until someone can show me that they can grow, I probably won't allow that much freedom.

Following an unstable, inelastic process can also be harmful.

It takes a lot of common sense, but it's a tricky thing and it all depends on developers and organizations. No one size fits all.

Personally, I prefer the freedom to try new ideas, new methods, new processes, but I think it should be self-regulating. That is, I think that methods, processes, etc. Should be helpful. Demanding freedom of personal expression in a team environment is probably not a good way to build a team, but I think the team should be open to improvement with new ideas. Once the process / technique has been accepted by the team, it would be counterproductive to keep pushing on your own path (even if better) if the team doesn't see it the way you do.

This is an invalid question. You can exercise your freedom to follow the process, or you can use your freedom to not follow the process. Whether you follow the process or not, you still have freedom.

This is a false dichotomy. The superimposed process does not correlate with success. For example, in telephone companies, there is a huge amount of process imposed on software developers (naive reading of "waterfall development") so that a lot of time is wasted, writing detailed project documents, and then when the software is delivered to customers suddenly find out that something what they asked for was not what they wanted. At this point, resources are almost depleted and everyone is losing. The superimposed process kills projects.

On the other hand, when Amitabh Srivastava introduced some basic parsing and testing requirements in the Windows team, the error rate dropped and, at least among my friends at Microsoft, productivity and morale improved. I'm guessing something similar happened in the KDE project when they started requiring everyone to use valgrind . Suddenly, there are more memory errors and incomprehensible kernel dumps.

In general, I find it more efficient to impose useful tools than to impose processes. Evidence for or against a tool's usefulness can build up pretty quickly. The only "process" I have seen consistently successful is that more than one pair of eyes must see the code. The mechanism by which this view is achieved is irrelevant.

Freedom for developers is another matter entirely. I am lucky to have a job where I have almost complete freedom to choose everything about my development environment. (Example: I work at a Red Hat store, but I had the budget to buy a computer and install Debian.) Since I have over 20 years of experience in software development, I can usually make pretty good choices about which languages and tools to use. But the flip side of this is that I can be quite productive in any language or environment. Using perl or C ++ can slow me down by 2 or 3 times, 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 in terms of languages ​​and tools, and who would root for the wrong tool to work with if given the freedom. I was once asked as a consultant to try to help the group speed up a compiler that took 24 hours to compile small programs. It turns out the people who wrote this were expert system people and they wrote the compiler using a rule-based inference engine. They made it work, but it was the wrong technology for the job.

I've also seen that limiting a developer to a specific environment or language is not a guarantee of success. I consider myself a very poor perl programmer; I mostly view perl as awk on steroids. I'm a complete idiot. And yet I had to deal with perl code written by others, which was much worse than anything I could write, because they never learned to think about problems or how to organize the code.

I think I'd better stop ranting.

Working in larger teams is the value of established, documented processes.

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

Once 10 people have to collaborate on something, you need at least some ground rules to keep everyone on the same side.

When you do a project with 100 people, you won't get anywhere unless you have specific rules and a well-defined process.

Personally, I would prefer that I could do whatever I want and everyone else worked in a rigorous process; -)

There are various aspects of freedom. When you can't manage to change half of the code because it's already "tested" (even if it's poorly coded), I'd say it's a case where you need freedom, but I don't think you are talking about it.

Freedom of the hacker style, using whatever tools you need to solve the problem, and solving the problem as the primary goal just scares me these days.

I've never seen any code that didn't need to debug / fix at some point, and debugging / fixing always seems to take longer than the original coding, so the first round of debugging / maintenance / improvement as much as possible is your main goal ...

This conflicts with Freedom, because Freedom often implies that you can choose mechanisms that will take more time from other people — and it’s most likely that other people will be doing this first round of service.

What if you become a lord of the freedom to be creative in new design areas rather than reinventing another development process?

"Success versus freedom" implies that if you can make decisions, the program will not be successful.

I think you really need to rethink this. In my experience, developers need to be FREE to choose the best implementation method, if, after reviewing better than "tried and tested" methods, it will be stored and used by the rest of the team. But they still have to ensure that the code they write SUCCESSFULLY performs the tasks they need to do.

"Freedom" in this case just seems like an emotionally positive word associated with an unpleasant concept. It can just as easily be replaced by "stubbornness" or "negligence." Even the question itself is formulated as "what I want to do" and "what might work".

Of course, everyone can freely choose any path. But I personally will not devote a moment of my life to something that I don't care about, and if I took care of that, I would do everything I could to maximize the chances of success. I don't see this as "restrictive" at all.

The question of whether to adhere to conventional wisdom or "think outside the field" is always a big one in most disciplines, not just programming. I think this needs to be addressed on a case by case basis.

I've been to conferences where the most popular articles seem to have been in-depth analyzes of things as they are. Unlike SO where ideas are popular, voted.

It would be good if there were no serious problems in this area. A lot (if not most) of the software is still too bloated (IMHO) and suffers from chronic performance issues. Things-as-they-are stable, but are they good enough?

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

I'm glad SO allows non-standard ideas to be discussed, not as flames, but as ways to question the status quo.