You’re a Bad Programmer, Really?(codemonkeyism.com)
codemonkeyism.com
You’re a Bad Programmer, Really?
http://codemonkeyism.com/bad-programmer/
4 comments
Good points. There does seem to be a trend for articles to have a theme of: "X is bad, embrace it." (Although, a lot of the time this is simply intended as irony, it can still be misinterpreted by a reader.)
In my humble opinion, the positive take away of this article is rejecting that mantra and focusing on becoming better.
In my humble opinion, the positive take away of this article is rejecting that mantra and focusing on becoming better.
You are right, but the author still has a point: even good programmers can't implement an impossible specification.
I think the author missed the point of Richardson's article. It's not about just accepting that you're a "bad programmer" and calling it a day, it's about accepting your limitations and constantly trying to improve your abilities and the tools you use. I think both of these guys are arguing for the same thing - don't get complacent.
I also read the original article as meaning that you should be humble about your skills and acknowledge to yourself that you might not be the rockstar developer your pretend you are. Less posturing and more knowledge that's what I want.
The only real wisdom is knowing you know nothing (Socrates)
The only real wisdom is knowing you know nothing (Socrates)
completetely missed the point of the original post, it looks like he just got insulted by its premise without reading it or at least figuring out what it was supposed to convey
> You’ve guessed it, Scrum adresses all of these resulting in 99% – 100% on target delivery. So it’s not due to bad programmers if an agile process can fix this.
At that moment I was tempted to perform a violent facepalm. He cites these issues as if a large project is just a five-person team sitting in a room failing basic communication. These aren't even straw men, they're more like paper dolls in a forest fire.
The obvious difficulty in managing >$10m projects is gathering and coordinating requirements, and distilling out from that workloads that can be implemented by individual programmers. This is a monumental problem. I'm guessing the majority of large projects never even come close to having an internally consistent spec without logical conflicts. The problem is that for software of this complexity it is impossible for any one person to have visibility into the whole scope of the project.
In order for projects of this scope to succeed what you need is several levels of extremely talented management with good technical sense in order to allow requirement conflicts to travel across team boundaries efficiently, and to make sure that the right domain experts can be brought into to correctly solve any conflicts that do come up.
To simply parrot the name of some agile methodology and then claim 99% success is an embarrassing display of ignorance for someone with ostensibly decades of experience.