While the user who asked you which specific techniques you mean has a point, I'll go out on a limb and say that the more bureaucratic of this stuff is total hooey. It mostly exists to provide the illusion of control over software development (because how software development really works is either not understood or is incompatible with existing structures). A lot of it comes from ideas drawn from manufacturing or industrial processes that are profoundly inapplicable to what software teams do.

Look at it this way. When smart people do creative and productive work, they have fun. So if software development isn't fun, something's wrong.

Many software engineering methodologies are built so that you can take a large team of mediocre engineers and set them on their merry way. This is a fact of life for the majority of the software industry.

When you start a startup, you probably (and should) have a small team of excellent hackers, so you can get by with just doing smart and logical things instead of following so many rules.

Growing your startup and engineering team does change how small your team is, and how excellent your hackers are. Add process as needed, shake and bake.

I would say much of the processes are useful, but don't take any of them too far. Unit testing, continious integration, version control, regression testing, and building your software in iterations are all things that are important for building good software.

If it's just two people in a garage than some things aren't as necessary as others, but as you build a team you'll need all of these.

For a startup other things like UML diagrams, pair programming and etc aren't necessary.

This question is kind of vague. What "software engineering techniques" specifically are you talking about?

Maybe the whole software engineering subject is rather vague in my head. What my teacher told me was that there's basically two paths: traditional software engineering and agile methods. The course I'm taking on the university is about the traditional software engineering. So I'm talking about that.

What they have presented to us thus far is a lot of documents, each with a different name. You're supposed to fill each document in each stage of development, called the iterations. The teacher even showed us a table about the software development process, and according to that table coding is only a small part of it. Frankly, I always thought coding was almost all there is.

So all that got me wondering if all that bureocracy gets used in real life. After I read "you weren't meant to have a boss" I thought all that software engineering stuff related very closely to what he describes as a consequence of big companies and lots of people working together.

Your instinct - that it looks like a bunch of bureaucracy - is exactly right. These courses are designed to churn out IBM or EDS "consultants", so they can do CYA -they followed all the rules, so they are safe.

There's a lot of agile floating around, so that seems to be useful for a lot of people.