This afternoon, I gave another talk at TrueNorth PHP. The talk is a version of a previous talk that I gave on Object Oriented Design. I’ve changed it significantly, so here are the slides.

Today’s post is in response to an article that I read yesterday entitled They Write The Right Stuff. It’s a very interesting and insightful look into one of the most complex and critical pieces of software ever produced (also one of the most expensive). I think we can learn a lot from what they are doing, but I also think we should avoid copying what they are doing. The point that’s missed is practicality.

Every developer who studies computer science (and most who haven’t) has heard the phrase “Garbage In, Garbage Out“ before. It’s such a logical concept that it’s almost beyond refuting. Almost. While the phrase still definitely holds true for some situations, it doesn’t hold for most. How can such a logical and straight forward saying lead us down the wrong path?

“Don’t Reinvent The Wheel” is a phrase that we hear used all the time in software development. Usually it’s used in the context where a library exists to do what the user wants, but they are writing their own. While the sentiment is usually correct, I can’t stand the implication of the phrase. Therefore, I can’t stand it when people use that phrase without understanding what it really means. Let me explain:

In response to last week’s ask for questions, I received a number of questions that I’d like to address. Since it would only do the question justice to have a dedicated post for each question. So I’m going to try to do one post per week on a user-submitted question (probably on Wednesday, but no promises). This week’s question is a rather abstract one:

I’ve been learning a lot about service layers and managers and domain objects and one thing really confuses me. Why is MySQL being turned into a non-relational database? It has so much power, so much flexibility, but it seems like many programmers want to abstract it to the point of near uselessness.

Now, there are so many facets to that question that it’s hard to find a starting point. But let’s try:

A few weeks ago I was sparked into a twitter conversation with Larry Garfield (@Crell) about the value of comments in code. Really, twitter is not the best place for that conversation, so I decided to write this post to illustrate my beliefs on commenting. Let’s start this story with the tweet from Larry that set off the conversation:

Nothing drives home the need for good code comments like working on code that doesn’t have them.

A pretty innocuous comment that is quite insightful. But that led me to respond with:

Nothing drives home the value of good, clean code by working on code that doesn’t need comments.

That led to an interesting discussion that just couldn’t fit on twitter. So let me explain…

Here are the slides from my presentation at NYPHP on STUPID vs SOLID development. Click through to see the slides.

Lately, I’ve found myself in a number of discussions about Technical Debt and how it applies to project development. Overall, I think it’s a very powerful tool that – when used wisely – can be a great asset to any team. It seems to me that most of the people that I’ve been talking to really don’t agree, and see Technical Debt as a plague that should be eliminated at first sight. So, I figured I’d share my opinions, and see what you think…

Quite often we see people talking about the best way to approach a problem. Usually this involves taking a relatively simple concept and making it fairly complicated to make it as flexible and maintainable as possible. While I’m all for maintainability, I think that sometimes we miss the point that it all depends on context. It seems like most people don’t understand the difference between good and good enough.

Part of being a developer is making design decisions based on conflicting goals. Our job is to choose the line that’s appropriate based upon our experience and the needs of what we’re doing. But there-in lies the problem: How do we know where that line really is? How do we know when we’ve actually reached the point of good enough?