KISS and YAGNI

blog
1

Microsoft performance guy Rico touches on a topic near and dear to my heart

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/10/kiss-and-yagni.html
2

I agree with “sam”. Can we see some examples of a good/bad obj model?

3

re: " Build what you need as you need it, aggressively refactoring as you go along; don’t spend a lot of time planning for grandiose, unknown future scenarios. Good software can evolve into what it will ultimately become." From the Originator.

You must like Italian food…because that sounds an awful lot like a recipe for “Spaghetti”.

4

So, so true…

5

Your mantra is that over-engineering is bad. This is a pretty safe stance, given that “over” anything is bad (from an engineering perspective, that is, overman on the otherhand, is a taught rope…). What you fail to do is to quantify “over”, simply stating “Don’t use fancy OOP features just because you can.” Obviously if the only reason you can come up with for justifying an architectural decision is “because I can” then it’s probably not a good justification.

But the truth is there aren’t a lot of “fancy oop features.” There are a small set that address a large set of structural concerns. OO’s mantra is “I am the machine that modifies the state that pertains to me,” a concept borrowed from more mature engineering fields. In the same way that you didn’t use global data in VB6, or C… OO just gives you a structured set of extensions to excercise the same virtues.

Still, you’re right, quite a few programmers do not use [or perhaps know how to use] OO effectively. But I would wager that these same people would make similarly bad architectural decisions in a procedural or functional environment too. OO is a tool. Screwdrivers don’t kill people, people do.

I recently started using AspectJ on some project at home. AspectJ is a set of extensions that let me address and isolate cross-cutting concerns. It works beautifly, makes my code more clear, less littered with redundancy and makes me more prodective. I consider it a good tool, despite those who would abuse it.

Perhaps you could quantify your views… what does a “simple” object model look like compared to a non-simple or malignant design?

6

I’m a professional hobbyist programmer and I’m working on about 4 projects at once.

Mainly what I’m doing is building up this one as a “really good framework” so that the others can look really spiffy and play nice. I’ve noticed things like having a common About Box would be cool, MDI Doc/View processing, and a couple of other things I could factor out into their own processes would be ideal.

I’m not doing that though. My goal is to make the app in a typical VB style: Everything in one place so that it looks crappy, barely functions, but gets the job done. (Okay maybe it’s not typical VB but it was MY typical VB). Once I’m done I’ll take out the bits I know I’ll reuse, and build OOP around that. Will it be version 1? No. Version 2? Most likely. As each app grows I’m sure there will be something I can add to the functionality of the objects I made so that they perform better.

I always make that initial 1.0 crappy version though. It runs, proves that I can do it, but the code will stink completely. Version 2 or the mystical version 3 will be where the money is at, as if I’d charge for the lame things I happen to be making right now.

Honestly though, if I tried to go OOP from the beginning I’d still be in design phases trying to build up frameworks and redoing that. Rather than having a functioning product that gets the job done, I’d be spending countless hours on something I’d probably abandon within a weeks time. Then again I’m teaching myself with no idea of design guidelines, I patch together .NET code by searching for relevant information, and my knowledge of debugging comes from SalesLogix where I have to use MsgBox() to show anything useful. SalesLogix uses a scripting debugger now, but I blame them for all of the bad programming practices I’ve held onto for the last 5 years.

7

While I do agree with KISS and YAGNI, I also adopt many other agile methodologies. From your post I almost get the impression that you attempt to avoid using OOP (Object Oriented Programming) OOAD (Object Oriented Analysis Design) practices if possible. I on the other hand embrace OOP OOAD and attempt to take advantage of their powers whenever possible. By doing this am I somehow complicating my application/architecture? Personally I think not.

8

Don’t Repeat Yourself is the goal I shoot for, not OOP per se:

http://www.artima.com/intv/dry.html

Sometimes OOP is the best way to achieve that, sometimes it isn’t. Starting out with “well, we better use objects all over the place because there’s no other way to re-use code properly!” is a self-defeating exercise.

9

Also, I spend a lot of time cleaning up behind people who set up grandiose object models that didn’t work out.

Oh yeah? Any that I’ve ever seen? :stuck_out_tongue:

The way you get rid of O-R Impedance issues… is by not using the R. http://www.intersys.com. Or by using something like http://www.hibernate.org/. The correct way is certainly not to let the database dictate your software design.

10

I refer you to Paul Graham’s “Why Arc Isn’t Especially Object Oriented.”

http://www.paulgraham.com/noop.html

Also, I spend a lot of time cleaning up behind people who set up grandiose object models that didn’t work out. A lot of it is the Object-Relational mapping problem, aka the Vietnam of our (coding) generation:

http://www.neward.net/ted/weblog/index.jsp?date=20041003#1096871640048

12

I remember I went through a phase during my junior year of high school, in C++ class. (It was taught like straight C with iostream, BTW.)

I went through a phase of using for loops for everything. If I could do it with a while, I used a for. It was the most complex programming structure I fully understood at the time, so I used it like it was the pinnacle of all computer science up to that point.

13

I have to somewhat disagree, based upon the fact that I’ve seen every company I have worked for create a larger mess by not accounting for even short term needs in their designs. -you forget that once you have set the bar for productivity based upon this model then no one ever gets time to refactor or enough manpower to dedicate to it. We live in a world where we are constantly called upon to deliver new features with a breakneck pace which means no one is developing a sustainable archetectural practice. NAGINI actually creates more complexity over time as people try to bandaid and add more boxes on top of an already fragile structure. Some forward thinking and planning is good.

1 Like