I used to say “Don’t hack core, make a plugin. Don’t make a plugin when you can edit your functions.php. Don’t edit functions if it’s a one-liner in your .htaccess.” The concept behind it was that people tend to over-complicate things by over-coding. I don’t say that much anymore, since I’ve found that plugins are more useful than functions a lot of the time, and really those are theme specific. But I maintain my basic argument that the simple way may be the best way.
No software design is perfect, and much of picking the software you use comes down to personal preference, at the end of the day. I worked through Y2K in desktop-software, testing it and validating its usage. One of the many things I learned was that personal preference will kill you, and spending a lot of time customizing an interface to be perfect for you is time wasted. At work, I use the bog standard Windows XP install. I have no customization on my desktop, fonts or display, save to make the screen resolution something easy on my eyes. The rest of the time spent making it ‘pretty’ is wasted for the purpose of work. My desktop is my desktop. The software I install is as much customization as I ever get.
I also don’t generally customize my fonts in applications. Again, this is time wasted, and minutia I will have to remember later on when I inevitably re-build my computer from scratch. The only ‘customization’ you should be doing is adding in that which is required to use the software (user name, server name, passwords). And all of those should be saved in a config file, call it a day. The exception to this rule is how I customized Putty, but again, I saved the configuration in a putty.reg file (I know, I know) and when I have to reinstall it, I re-load that. Anything I want to customize must be easy to re-apply, both technically and mentally. I don’t want to spend an hour farting around trying to remember ‘what was that setting…’
Similarly, when I look at wanting to do something on a website, I take the time to determine if this is a one-off change for one moment, or something I want to repeat. I think about how the change is going to affect the overall workflow of my day-to-day functions. Will this improve everything or just make today easier. Can I apply it to many things, or is it specialized and localized. Most importantly, do I need to recode to do it, or can I utilize something that already exists.
It’s not a factor of being lazy, though like everyone else in the world, I am. It’s a factor of reinventing the wheel. Many times I end up writing from scratch, but other times I’ll sit and think ‘You know, this works about 90% of what I want. I’ll just change it.’ Now, as a good little coder, I fork my code when I do that, or split entirely and make something with a new name. I don’t ever hack core. If I can’t do it in a hook (be that a function or a plugin) or a config tweak or a customization, then something’s wrong with what I’m trying to do. Or possibly the way I’m trying to do it.
Sometimes I find the best solution is to accept the limitations and make it the best I can within them. That’s always a fair cop too. But I never presume there’s only one way. I’ll chase the rabbit down the hole, through the tunnel and out the other end multiple times, in order to come up with the best way, not just to fix the problem I’m having today, but to make sure I fix it for everything, without impacting anything, and that it’s the right solution for the long run.
This process usually begins with writing down, in plain english, what I want to do. Then I study the source code to find out where to change it. At this point, I stop coding again, and go into the documentation. On WordPress I review the trac tickets related to this portion of code, and for vended software I actually read their documentation and support sites. You see, now I want to know if I can sort out why they do things this way.
For example, if I wanted to make the new WordPress 3.1 admin bar show up for all users (like the BuddyBar on BuddyPress) and have the login option (like the WordPress Admin Bar on WordPress.com), I could do this via hacking the code easily. But. In reading JaneForShort and Nacin’s comments in trac and on IRC, I followed their logic as to why this isn’t available out of the box. After all, these guys have access to the code on WordPress.com, so they could have lifted it whole sale. While I can see value in having it available, it would include too many options for a first-round change in 3.1. Maybe this will start to slide over in 3.2, but for now, the idea is to get the world used to it, so your options are on-or-off, and that’s it. I then wrote a new plugin, pretty much a raw duplicate of the admin bar code, that disabled their admin bar and ran mine instead for tests.
Perfect? No, but it lets me test what I want without hacking core. Right now, I can see exactly why you don’t show the bar for logged off users: it’s ugly. This is something I knew going in, though, because I took the time to understand why the code was done the way it was. Do I agree with it? Yes and no. I agree that, as a short term goal, it was better to fix what was in and add more later. I don’t think this should be the end of it all, and I’m sure it won’t be. Growth and change are inevitable in most things.
The real decision is if I want to implement my code now, or wait till 3.1 is out and then posit it as a change on trac. In the end, I’m playing with it on my desktop instead of anything else. I want to see where the thought processes for 3.2 takes things, and I want the time to clean up my code. It might be a passing fancy right now for both me and WordPress. It might be something I go “Oh! Shiny!” and change my mind on. But I have the time because this is something to interest me and it’s not a need.
That’s the real crux of the matter: wants versus needs.
Knowing the difference between a want (like shiny flash graphics) and a need (readability) helps me determine if the change I want to make is worthwhile. Knowing how to look at my desires and separate them from the demands is imperative when you’re writing code or building a house. You may want all the cool bells and whistles, but you have to take the moment to strip them out and get to the basics. There are always basics to fall back on, and ignoring them due to the blindness of bling will hurt you in the long run. Don’t let your customer base pull you from that track either. Sure, they want all the features the competitor has, but pay attention to the downsides of that, and educate them. If they’re right? Of course you should listen, but it’s your job to teach the customer to have realistic expectations. Yes, you can remove the /blog/ stub from your MultiSite installation, but there are risks. Be aware that the shiny removal may not solve every problem you’re having.
When do you code and when do you say ‘This is what it is’? There’s no right answer. But knowing how to think through it and apply your mind to the entire problem, not just the ‘this is what I want now’ but also the ‘and this is the big picture’ will help you in every aspect of your life. Listen to the wants, respond promptly to the needs. We would like a jacuzzi tub in the bathroom, but all we need is a shower. Don’t let the fancy spigots distract you.
Comments
4 responses to “When to Code”
People forget that settling and compromise actually get things accomplished. I had a client that gave me a great saying – we had been discussing a change they *wanted* but maybe didn’t need. I explained the amount of time, work and difficulty involved.
“Oh,” she said “So the juice ain’t worth the squeeze.”
States it perfectly.
If you;re coding for literally hours to save a few minutes.. well, you didn’t, really.
Unless the few minutes are going to be saved over and over again, in multiple ways 😉 I spend a lot of time automating things, so I do tend to spend hours coding something that only takes 5 minutes to execute. But it’s better to learn the code in those cases, than to do it all manually 😉 Again, comes from looking at the big picture. Want to rename 100 files? Code! Want to rename 5… Dude.
Yep, don’t hack core 🙂 Good observation that some things can be done easily by hacking core. Other than for prototyping the merge, I haven’t hacked core in ~3 years.
In every instance, the reason I hacked core was it was the easiest way to get the functionality I needed. But, once I started doing work on other people’s installs I made it a personal policy to not hack core. And, in process learned that hacking core is never necessary 🙂
I started learning not to hack core in the MediaWiki .9 days. I have a wiki elsewhere, and I wanted to make a LOT of changes that you just couldn’t do at the time via themes. So every single upgrade ended with me spending two hours matching file changes I stored in an XLS file (yeah) with filenames and line numbers and before and afters. Once theming got settled there, it was so much easier just to yank the stuff out! But sometimes it’s really the only way around a problem.
Of course, these days when that happens I think nasty things and get another web tool to do the job! 😉