Introduction

If you’re looking for instructions on how to set the SelectedItem property of the ASP.NET ListView control, you’ve come to the wrong blog. This is a blog about big ideas, about where the software industry is headed, and why the conventional wisdom regarding the proper way to develop software is often just plain wrong.

You see, computer programmer types like to think that they are logical thinkers, but I’ve observed that, just like in any other industry, they mindlessly follow the herd and adopt best practices like object oriented programming, unit testing, design patterns, “agile” methodologies, etc, which are all actually bad practices and lead to overpriced low-quality bug-ridden software.

* * *

(Of course there is a legitimate need for information like how to set the SelectedItem property of the ASP.NET ListView control given the poor Microsoft documentation.)

Comments

[Mark Hoffman]

Look forward to your blog...

Just curious though, you claim that OOP, unit testing, design patterns and Agile are all bad practices that lead to low-quality, bug ridden software. What, in your opinion, is the proper way?

I ask because our industry has never had a time when it was known for producing quality software on time. So, if these practices result in bad software, what was it that previously allowed it to be developed properly? And if it never was done properly, what practices do you recommend?

Perhaps you can write something about how unit testing is wrong and leads to poor software. Forget TDD, I'd love to hear a reasoned argument how not unit testing software leads to more maintainable, quality software.

I'd also be interested to hear about how you develop software. What size is it? What are your processes, or lack thereof? Are you a fan of waterfall? Just put a bunch of devs in the room and have them figure it out? Or do you have a process intensive approach with lots of documentation, change request forms, etc?

[Plaristote]

I can agree about agile and unit testing being bad practices (in some cases).

But OOP and Design Patterns ?
I wasn't teached OOP or Design Patterns. I was just told to write code for a few years, and as time went by, I developed my own style of developing: I made it easy to read, short, re-usable... as much as I could.
I only understood I was doing OOP after being teached what OOP was.
The same thing happened with design patterns...

And ever since I started using these practices, I write code much faster, with much less bugs, and I can change its architecture so easily.
I wouldn't go back to anything else. Encapsulating features is the way to go. And OOP is the perfect tool for that.