Jeff Makes Software

When I worked at Penton Media in 2000, the promise the Internet held was obvious to me. Here I was at a business-to-business media company that made its money connecting people who need to buy and sell each others shit. Some of those markets were very vertical, you know, niches. It was expensive as hell to put out those dead trees and do trade shows, but look at how cheap it was to stuff on the Internet!

I'm not going to call out any particular blogger on this, but there appears to be a lot of bitching and moaning since Jamie Cansdale announced he was going to begin charging for commercial use of TestDriven.NET. I say, get over it.

Bill will still be the chair of Microsoft, but he's going to step away from his executive role. He wants to spend more time with his charitable foundation.

So here's the thing about test-driven development. I think it's awesome because it forces me to be more focused in my design and I know when I break something if I have to revisit it. But I suck at it.

I test too much or too little. Sometimes I write tests after the code because I want to get something working quickly. I don't break things into small tasks like I should, and I let big picture temporary roadblocks slow me down.

The bigger realization that I've come to is that TDD is amazing and awesome for back-end development. When I was first exposed to TDD, it was in an environment that was 100% executing code with no UI, like mainframe replacement stuff. Indeed, this development methodology is a big deal because you really don't have any other way to understand and be sure that the code you're writing actually works.

When you're building a Web app, especially on the considerably smaller scale involving a team of one, TDD can get in the way. A lot of the time, I want to hack out some UI and start to drive my requirements from that. And if you think about it, that really makes more sense, because the UI helps define the solution to the business problem you're trying to solve. I'm sure that some consultants would freak out hearing me say that, but it's so true. The UI is something tangible up front, not a bunch of abstract bullshit that won't actually translate to something useful.

That said, there are a lot of cases where TDD makes sense even in this scenario, because it provides a great apparatus to make sure what you're doing works. It's great for testing (and maintaining) data access code in particular. It also works great for making sure some kind of calculation or text manipulation performs as expected.

So as is the case with most things in life, I'm finding the all or nothing approach using a particular methodology is just not practical.

In my relatively short career in software development (which is still like 50 years in Internet time), I've been exposed to a wide range of development methodologies, project management and general dev culture. The easy trap to fall into is trying to apply what you learn to every new situation.

There was a big uproar over CMP and O'Reilly sending some guy a C&D letter for using the term "Web 2.0 Conference" in that those companies are using it as a trademark.

As it turns out, I've already missed one of the milestones I set in my last post about my forum app rewrite. Instead of beating myself up over it, I'm just going to pat myself on the back for working on it at all, since this is something I've been wanting to do for, uh, more than two years.

So far, there are about 4,700 lines of code, and 42% of that is test code. I know that I don't write particularly good unit tests, because I just can't always burden myself to think about them the way I should. I test too much or too little. Since so much of testing exercises data CRUD, I can say that it does serve me well in that it's easy to add or remove something and no immediately if I break it. Especially in an application like this, so much of it is data access.

So what do I have so far? Membership, Roles and Profile are good to go with custom providers. They're not fully implemented, because there are certain things that, frankly, I don't need and I'm not going to waste time on them just to say that I fully implemented a provider. I'm not even supporting anonymous profiles. I also have fairly extensive security logging in place, which is something I've wanted for a long time. I think it's up to like 14 events that are captured now.

Next up, probably before I bang out the meaty parts of forums, topics and posts, I want to figure out a clever way to encapsulate permissions. I've never done that very well. You know, based on your roles, what you can read, post to, edit, etc.

The 37signals guys would probably freak out that I haven't done any UI yet. :) Granted, I already have a pretty good idea of what my UI should look like. But for all of their crazy "getting real" talk, I can identify with a lot of what they say. Some of it just isn't practical in real, large-scale software development teams, but there's truth to a lot of those beliefs as well. For example, I agree that meetings are toxic, as they say. On the other hand, I think worrying about scalability later is a bad idea, because if you get it really wrong up front, you're looking at a total rewrite later, and who has time for that?

I hope I can continue to have this level of energy and wrap this project by the end of the summer.

As I've said before, sales of my book have generally sucked. Again, great reviews and lots of e-mail from people who really liked it, but A-W did an incredibly shitty job marketing it (putting ASP.NET 2.0 on the cover would've been a good start).