next »

[14113]

Haha, I have a different structure to your first point, it's more about what is an applied form of what, ie: history is just applied sociology which is just applied psychology, which is just applied biology, which is just applied chemistry, which is just applied physics, which is just applied maths.

On the software engineer thing I couldn't agree more. I'm still in high school, planning a job as a programmer, and the thing that terrifies me most is the culture of bad management and misapplication of programmers by management who plainly don't know what the programmers do all day or who they do it, only that it makes money and they want them to make MORE money, which they try and achieve by throwing more programmers and increasing the hours until it all collapses and the project turns into a blackened ball of despair and bugs.

[BorisTheBrave]

Oblig XKCD

[Vino]

The amount of engineering a person should put into a particular feature or piece of code varies greatly on what it's for and where it is. If it's the core of your engine then you need to spend a lot of time on it. If it's an ancillary bit of extra code on the side then no need to over-engineer it. Thinking about the overall design of software from the get go can be time consuming and many things can't be foreseen ahead of time, and chances are that unless you are being paid a lot of money to write a particular piece of software then not enough people will use it to warrant spending too much time in planning.

[Taiko]

Programming is all about code.  Focusing on what you're trying to do is software engineering.

Software Engineering is all about drawing UML and talking shit and buying expensive bloated tech to look like you know what you're doing and get funded once again.

Programming instead is all about solving problems with algorithms, and it's a way of viewing things that can be applied to a lot of situations... so I'm with bateleur.

I have a hard time reading this as anything but a troll post, but I guess I'll bite.

Software engineering is about way more than UML.  It's about getting programmers to coordinate their efforts to solve software problems.  Things like version control, pair programming techniques, testing, documentation, etc.

You may not need UML for a quick indie game (although you might want it if you write software for NASA...), but I can't imagine a scenario where you wouldn't want to document your code or thoroughly test it.

To disregard software engineering as a discipline is a huge mistake.

[14113]

However to overuse it in a situation would also be a mistake.

[Taiko]

However to overuse it in a situation would also be a mistake.

Absolutely.  Software engineering is a toolbox of techniques.  You pick the parts that are appropriate for the job you are working on.  You don't need a chainsaw (waterfall development) when a handsaw (extreme programming) will do.

[14113]

Exactly, which is what annoys me when I see loads of blogs talking about agile, sure, it's a pretty good tool for a small team to use, but quite a lot of systems simply aren't suited to that, or should even use that; sometimes it's simply not appropriate.

[InfiniteStateMachine]

I've never been a big fan of UML, I do plan out my classes in other ways but UML always felt too cumbersome. Maybe my opinion will change after I work on a large project in a coder capacity.

[_Tommo_]

I have a hard time reading this as anything but a troll post, but I guess I'll bite.

Given the split, I would say that I was a successful troll 

Anyway I trolled (yes I did) not because I'm thinking that Software Enginering does not exist or whatever - I was arguing against the split between Software engineer and programmer.

To me this split does not exist: a programmer is a guy who solves problems using computers, and there are good programmers and bad programmers.
There's can't be a good programmer that can't use waterfall or proper documentation if needed, and there can't be a software engineer that can't use agile or hack if the situation rules that way.
So, there arent' self-appointed qualifications where you are the process you use - you are good or you are not, and languages and tools do not matter. Simple as that 

[jotapeh]

Can I just say I hate the term 'AGILE'? Nobody REALLY knows what the hell it is, or at least the companies that (attempt to) employ it certainly don't have a clue what it is or how it's supposed to work.

The mindless 'scrums', the complete chaos of people trampling over each others' code, usually all exacerbated by thoroughly unknowledgeable management ... I mean, what the hell does this diagram even mean?



Seriously this is the worst kind of buzzchart. In my experience, Agile development applied in large corporate scenarios usually relies on having one or two really smart chaps in your sea of programmers who run around implementing new code and fixing code that other people have written which doesn't really work the way it's supposed to.. When these one or two chaps inevitably quit, Agile falls apart completely.

Then again, I've only ever worked for one large corporation, so maybe there are others that do it better. (So far, I have not heard of any.)

However, one specific part of Agile that I think is very valid, is Pair Programming. I think anyone who has done this, even on a casual basis, has realized how much you can learn either by being the one doing the code or the one observing/reviewing.

We now return you to your regularly scheduled discussion of UML. 

[bateleur]

Nobody REALLY knows what the hell it is

That's really not true!

However much corporations may sometimes get the wrong idea, the basic idea is really very simple: get something really, really simple working and then move from one working, stable release to the next, adding features in increments that are as small as possible.

[Taiko]

However, one specific part of Agile that I think is very valid, is Pair Programming. I think anyone who has done this, even on a casual basis, has realized how much you can learn either by being the one doing the code or the one observing/reviewing.

Pair programming is really cool.  I admit to having hated the concept at first, but now that I've done it on a couple of projects I see that it makes programming more fun (if you get a good partner).  Not to mention you end up writing better code faster.

[BlueSweatshirt]

I had never heard of pair programming. That's a pretty sweet idea. 

[Skomakar'n]

You're at this level now, OP:

[st33d]

I split this thread from The Happy Programmer Room.

Are you talking about me or the person who was a the beginning of the split?