Max Kanat-Alexander

Hahaha, I think maybe I should update the Release Guide to say "Okay, and now blog about it!"

No, but seriously. We released Bugzilla 3.0rc1 today, which gets us that much closer to a final 3.0 release. This one's actually pretty stable. The code's been running on bmo and we did QA on it, so we're pretty good. I don't forsee any major problems between now and 3.0 final. In fact, this is one of the first times in Bugzilla's history that "Release Candidate" really means "Release Candidate"--that is, I could release the code that we have now as 3.0 and be totally happy.

Right now I'm just waiting for the web site to update itself...oh, okay there it goes. Apparently the Netscaler caches the Bugzilla pages for far too long, and justdave had to clear its cache. I don't know what's up with that.

Okay, I think that makes it bed time. Seriously.

-Max

(This was originally a comment on bug 345100, but I wanted to expand on it and post it generally.)

A common mistake that people make is designing too far into the future. The right way to go about development, particularly in an open source project, is to design for the specific requirement (singular) that you know is broadly needed, and implement that on top of the system you already have. If that can't be done, or can't be done with simple code, then you do re-architecture. Rinse and repeat.

Violations of that principle are what lead to crazy, messy code that nobody wants to maintain after a few years. People design massive changes that do everything in some extremely specific way, based on a nearsighted design. Then, much later when somebody comes up with some feature that you never thought of but would be extremely useful, you can't implement it because you've got this unwieldy very-specific design that handled only what you needed at the time, and can't be extended to do what you need now.

What do I mean by "nearsighted design?" Basically, code should be designed on what you have, not on what you think you'll have in the future. It should be designed for the requirement that you have right now, without excluding the possibility of future requirements. If you know for a fact that you need it to do X, and just X, then JUST DESIGN IT TO DO X. I've made this mistake myself--certain Bugzilla tables contain an "is_active" column that has never been used, because I put it there in anticipation of the future, instead of for something that I needed right then.

A general example of this problem is Bugzilla's BugMail.pm file. It does everything and the kitchen sink, and was pulled out of an old script called "processmail" which basically did the same thing. Instead of being carefully designed and engineered piece by piece, it was designed way back when as a single, massive whole. As a result, nobody fully understands it today, and it's pretty difficult to add new features there. Want to make Bugzilla send HTML mail? Ohhh, good luck. As a result, I'm going to have to redesign the module, when it should have just been designed in the first place.

It's fine to design for what you need at the time, as long as it's a small design. So, I just make all designs into small designs, and we're fine. That's why I'm so adamant about "one bug, one issue." Because it encourages small designs, and it keeps code maintainable.

Maybe it's just a misunderstanding of what the word "design" means in programming. When you have a brand-new product that you haven't even made yet, first you find out what its requirements are. Then you write a program that fulfills those requirements. You write it in a way that it can be updated in the future for unknown requirements. That's where design falls in. You look at an individual requirement and you say, "Okay, how can we make this so that it works perfectly, and we can also extend it for unknown requirements in the future?" If you're at the point of the initial product design (that is, you don't have a product yet), you'll probably also want to look at the other requirements and make sure that your design isn't going to impede those. However, if you actually design any individual requirement correctly (or any piece of your program correctly), it's unlikely that you'll ever interfere with other requirements.

This is how many, many people can be working on an open source project simultaneously without knowing what the others are doing. They design their code so that it doesn't matter what's going on anywhere else, the code just works, and can be modified and extended easily by anybody. There are lots of ways to do this--they mostly fall under the rules for good object-oriented design. You can find those elsewhere, so I'm not going to go into them here.

Some people think design means, "Write down exactly how you're going to implement an entire project, from here until 2010." That won't work, brother. That design is too rigid--it doesn't allow your requirements to change. And believe me, your requirements are going to change.

Planning is good. I should probably do more planning myself, when it comes to writing code.

But even if you don't write out detailed plans, you'll be fine as long as your changes are always small and easily extendable for unknown future requirements.

-Max