Kevin Kaland's Developer Blog

Communication (usually) more important than speed

I figured I’d right about this since it came to mind and has come to mind a few times. That’s pretty much the minimum requirement for a blog post, right?

So, something I’ve discovered: Development speed is subjective, and (within reason), it doesn’t matter as much to the average client (at least, the average client I choose to work with) as much as clear communication and being kept in the loop as to where things are.

I consider myself a somewhat slow developer. Not incompetent slow, but maybe testing slow. I like to make sure stuff actually works. Sometimes I spend what I consider too long doing that, and sometimes I spend what I consider too long researching the problem.

Yet, no one has actually ever complained (at least, not to my face) about my speed of development. My theory is that this is because I communicate what I’m doing and get in touch if there’s a problem that’s going to take a while or if I’m stuck. I try to minimize the surprise factor as much as possible. I also express things clearly and, to the best of my ability, in terms that make sense to the client and their level of technical expertise.

This is starting to sound a bit like a sales pitch, which is far from my intent. I’m just thinking out loud a bit. And actually, this leads into my next point: the biggest evidence that I’m doing something right is that I’m pretty consistently booked out, and more offers of work are sent to me than I can take.

Also, someone once expressed a counterpoint to me that made sense. They said that even though I may consider myself slow, I’ll still be way faster at solving many kinds of specific problems than a newbie because I have domain expertise, have solved them before, or know where to look. And this is the harder part of development, I think…speed is just a natural result of doing it more (and actually, I suspect the really fast people probably just have lots of code they can look at and base stuff on…a.k.a. experience).

So, communication matters. Knowing about problems earlier will ultimately save clients (and you) headaches, which will in turn likely save money.

There’s a saying you hear sometimes in the professional community: “Pay me now, or pay me later.” Sometimes it’s about outsourcing to not-so-quality providers and then realizing the mistake.

OK, I’ll leave this here. Comment if you relate or if you don’t relate. Would love to hear from you.

Can exportables and client control coexist?

Here’s an interesting issue I keep encountering. There’s a client that has fast-moving needs, and nailing down too much in code without providing an easy way to change it doesn’t really fly. As a result, stuff like CSS Injector and lots of custom blocks are used, and these things aren’t particularly exportable. Or maybe they are. Features 7.x still hasn’t made the cut on the site.

My question is pretty vague really, but in a situation where circumstances such as these make it hard to fight for exportability, what’s a developer to do? Everyone knows it’d save time, but I think there’s a perception that it will make things harder to change (or make changes require a code push, which is on a release schedule).

I’m just concerned because the potential for human error is unlimited when all normally-exportable configuration more or less has to moved by hand (bundle_copy made it through - wish there was something that could diff and move pieces of Views views).

Ask me for more specifics if this is too vague. I’m figuring someone who’s been in a similar situation will get my point.

DrupalCamp Twin Cities party - a comparison to SANDcamp

So this title is a bit charged with meaning, but I’ll say upfront that I’m not really pitting the parties against each other. All DrupalCamp organizers could benefit from this post. With that out of the way…

A while ago I posted my feedback about the SANDcamp rooftop party: http://kkdev.tumblr.com/post/16683707117/feedback-on-sandcamp-bon-voyage-rooftop-party#disqus_thread

Tonight I went to the DrupalCamp Twin Cities party at Intermedia Arts, and it was different…different enough that I stayed the whole time. That is somewhat surprising, since I haven’t stayed for an entire party since Angie Byron came to Los Angeles at the beginning of 2011…and even then, I might have cut out a little early.

Here are the main reasons for this as I see them:

1. The music was at a reasonable volume. It was plenty audible, but it wasn’t deafening. It was easier to talk to people. I’m never a fan of the music, but it was tolerable.
2. There were lightning talks. That was the biggest selling point of this party for me.
3. It was a tasteful venue. Personal preference for sure, but I don’t hit the pubs and bars.
4. The atmosphere was just cool…and there was a ping pong table, which I made good use of.

So turning down the music + lightning talks resulted in a party that I think everyone enjoyed. From what I could tell, people could still wind down from the camp in whatever way made sense to them just as well even with the slight tweaks.

I go to the parties to chat and network, and I was able to do that in a casual environment, It was cool! Thanks @TCDrupal!

Tips on syncing Git branches, modules, and databases in Drupal?

So there’s a problem I keep running into, and I wonder if anyone has scripted anything around it or has a slick process. And that’s feature-branching against a DB-intensive project like Drupal. Often, I’ll feature-branch and then download a module and enable it. If I switch back to the mainline, that module isn’t there anymore, and Drupal/Drush complain. So:

1. Should I always add all modules that may be used in feature branches to the mainline first and commit?
2. Is there another way I can deal with this?

That’s really the main problem. Most other database stuff is inocuous even if it remains sitting in the dev database afterward.

Maintenance by host

The host is carrying out some preventative maintenance, so please stand by. Things should start working again soon; when you can access https://fillpdf-service.com again, it means that the service is operating normally again.

@sanebox I’m loving the filtering so far, but sometimes it seems a bit overzealous. That is to say, I get subscription updates from drupal.org when issues I’m following get updated. I want certain issue updates to appear in my inbox, and others can go to @SaneLater. It seems hard to teach SaneBox this because the sender email addresses are all the same. Does it eventually learn what’s different about the emails I’m training to INBOX and those I’m trying to @SaneLater, or is it based solely on the e-mail address?

I can forward you a couple examples of ones I want and ones I don’t if you like. Hit me back.

(P.S. Yes, I totally just used Tumblr for a long tweet. It’s great for mediumblogging!)

Working on finance system again

I’ve taken over tracking the finances again, so I’m probably going to be motivated to enhance things again pretty soon. I have to upgrade Drupal 7 and stuff as well.

There was a budgeting feature I wanted to put in so that I could finally stop using the old spreadsheet at all. That’s probably the second thing I’ll work on. The first is simply to tag expenses so that I can filter them more easily and see where I have missed adding some.

Another feature I’d like to add at some point, but about which I’m unsure how to go, is the ability to upload a CSV of transactions and have the system parse the dates and amounts and suggest to me which ones might already exist (and import the ones that don’t). If I really need this, though, I’ll figure it out. Again, the system is more of a way to make sure money isn’t just being spent randomly but that I at least know where it came from and where it went…and if I have enough. The active element of it (actually having to spend a bit of time on it) has been better for me than automatic budgeting in the programs in the past. Sometimes you want to check up on things. But I do want to automate the repetitive parts that don’t need a human.

I still might publish this as a Drupal distribution if enough people are interested. Guess we’ll see.