Found this article while reading Job Listings. Felt like Sharing. http://www.joelonsoftware.com/items/2009/09/23.html

It's a fun and feel-good article. The problem is that 90% of the people who read that article, sit back and grin, and say "yup, that's me", also need to read this article. That 90% includes everyone who reads that second article, sits back and grins, and says "yup, that's everyone else".

Quote: Original post by Kingerthethird
Found this article while reading Job Listings. Felt like Sharing.

http://www.joelonsoftware.com/items/2009/09/23.html

I don't know. There's also the opposite of over-engineering, and that's being totally oblivious to newer technologies, to the point of becoming obsolete and detached from reality. Both extremes are bad.

Over engineering certainly is a big problem. Then again, are people who claim that all OOP is the spawn of Satan and everything should be done in pure C any better ?

Quote: Original post by Yann L

Quote: Original post by Kingerthethird
Found this article while reading Job Listings. Felt like Sharing.

http://www.joelonsoftware.com/items/2009/09/23.html

I don't know. There's also the opposite of over-engineering, and that's being totally oblivious to newer technologies, to the point of becoming obsolete and detached from reality. Both extremes are bad.

Over engineering certainly is a big problem. Then again, are people who claim that all OOP is the spawn of Satan and everything should be done in pure C any better ?

I agree, it's a fine balance probably. During my job I learned to make more modest code so developers (including me) can read it and it just ships even if it's not brilliant and has some bugs. On the other hand, I also have experienced just pounding on rotten code to get something done will haunt you after a release with costly bugfixing and maintenance. Not writing a single unittest does result in meeting that first deadline, but what happens after that is also important...

Yeah, I could see this being both a good thing and a bad thing. As the saying goes 'busy people get stuff done because they are busy'. I've seen thing from both sides in the same project - ancient, crusty, hacked together VB code that had been ported to .Net, and overly-complex, uber-designed server side code. Both aren't fun to work with. Rather than doing a hackjob or an uber-engineered job, I'd rather just make it work and make it nice.

Do it. Do it right. Do it right now.

Get those three down, and you won't have any problems.

Duct tape programmers are the reason why some software ends up on The Daily WTF. Sure your go-cart can fly, but...oops...the breaks don't work for people between 178 and 201 pounds.

Quote: Original post by Sneftel
also need to read this article.

"You might be wrong about everything" is generally a good rule to live by.

Joel is beating up strawmen and arguing for nothing in particular. The only intelligible point of the article was made long ago as You Aren't Gonna Need It and Do The Simplest Thing That Could Possibly Work. They're not unqualified rules to be used in ignorance and isolation of everything else, though.

I was reading the thing, nodding in agreement, until I hit this gem:

Quote:
You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work.

Templates? Seriously? Templates are too hard to understand? They make things over-complicated? If anything, they make things much simpler, saving a lot of copypasta that's only a hassle to work with as project size grows...

Quote: Original post by Koobazaur
Templates? Seriously? Templates are too hard to understand? They make things over-complicated? If anything, they make things much simpler, saving a lot of copypasta that's only a hassle to work with as project size grows...

A template is a tool, like any other language feature or construct. They can indeed be very useful, but they can also be horribly abused. I've seen monstrosities of recursive template magic in production code, that even the creator himself could not decipher anymore after two weeks.

The same goes for multithreading. It's an incredibly useful feature. But nothing is worse than people using MT in production code without actually understanding it, while introducing bugs that are almost impossible to trace (especially if you have a shipping deadline).

I disagree with Joel over that one should entirely avoid these things. They are a vital part of modern software engineering. However, abuse of such features, especially by individuals that aren't competent in using them effectively, is just as bad.

Quote: Original post by Koobazaur
Templates? Seriously? Templates are too hard to understand?

This comment is a sure way to tell that you don't have a lot of experience with what can be done by using templates. Go and look at the source of Boost Spirit. You will not be the same person anymore...

(Not that I don't like Boost Spirit [grin])

[Edited by - Yann L on October 2, 2009 9:48:49 PM]

Quote: The problem is that 90% of the people who read that article, sit back and grin, and say "yup, that's me", also need to read this article. That 90% includes everyone who reads that second article, sits back and grins, and says "yup, that's everyone else".

After reading both of these articles, I'm not sure I identify with either. I mean, the idea of a duct-tape programmer kinda scares me. I don't want to work with hacked C code or an engineer who habitually does it, that can be harder to read (and make work) than any templated nightmare. As Programmer One puts it:

Quote: Duct tape programmers are the reason why some software ends up on The Daily WTF. Sure your go-cart can fly, but...oops...the breaks don't work for people between 178 and 201 pounds.

Not that I don't like or use templates, quite the contrary. But yea, you'll see some wild things with templates. I'm getting increasingly familiar with the boost libraries. It is a powerful library, but sometimes a given aspect of the library (many in fact) can be quite a bit to chew on.

Quote: Go and look at the source of Boost Spirit. You will not be the same person anymore...

I think spirit is a parser of some kind, right? I haven't used it yet, but if its anything like complex lambda expressions I totally believe you.

As far as overconfidence is concerned, I'm probably quite the opposite. Uncertainty is a persistent foe of mine. I know I've over analysed in the past (did it alot in college) and I'm sure I'm not alone here, but I do like to get my line of thinking straight. I would argue that a big part of the engineers job is R & D. Is it a pain in the ass, absolutely. I can't speak for everybody, but I'd rather hit a wall on paper than in code. That's why I got into the habit of re-factoring. I give myself x amount of time to generate a solution before I make myself just go through it. At least there is some fore-thought, and I at least have some background to go off of as a plug along. And if I don't like how it turned out, I chew on it some more and spit out part 2.