Category: Articles (Page 236 of 258)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

Stop Complaining About Customers

April 10, 2013 / Tom / 0 Comments

One of the things that I enjoy the most about Twitter is the ability to meet, greet, chat, and learn from other people in my field.

Granted, not everyone uses Twitter for the same reason, but I’ve really enjoyed getting to know certain people in my particular development space, and enjoy the conversation as much as the next person.

In fact, I’d go as far as to say that it’s helped make me a better developer because of the conversations that have gone from Twitter to this blog, or vice versa.

But there’s something that I’ve noticed on Twitter among my fellow developers – most notably freelancers or those who are at the head of smaller businesses – that I can’t seem to understand (or endorse): It’s complaining about customers.

Software Project Estimation: Free or Paid?

April 8, 2013 / Tom / 0 Comments

Ever since I’ve gone into business for myself, software project estimation has been one of those skills that I feel as if I’m constantly refining.

Sure, I have a process for how I go about doing it now, and I have open conversations with potential customers as I try to understand their core business need before I go off to estimate the project, but the truth of the matter – and anyone who’s ever estimated a project knows this – is that estimating a project is also a function of how well the customer understands their current problem.

By that, I simply mean that if a customer has a felt need and they have a vision for how their process can be improved, it’s easier to come up with an estimation for a project than for a customer who has a felt need but a vague idea as to how it may be solved.

There’s a lot that can be written on this topic, but I’m primarily concerned with just one aspect of estimation in this post: should estimates be free or paid?

Software Craftsmanship and WordPress

April 4, 2013 / Tom / 0 Comments

Earlier this year, I shared a post on why software craftsmanship matters in WordPress development. It stemmed from a Twitter conversation that I had with Dave Donaldson at Max Foundry.

In the comments of that particular post, Dave also followed up with this comment:

Just to be clear, my issue with the term “software craftsman” is that it’s taken on an elitist connotation by many people, and that bothers me. It also bothers me that there is some correlation between people who spout “software craftsmanship” but don’t actually ship anything.

I try not to spin my wheels on topics that I’ve already discussed in-depth, but I recently stumbled across another post by Uncle Bob Martin – arguably the biggest proponent of the software craftsmanship movement – on the 8th Light blog that brought up the same concerns that Dave mention.

Specifically, it discussed the “elitist connotation [demonstrated] by many people.” Call me naive but I’ve simply been missing out on the drama that’s been going on surrounding this entire “software craftsman” thing.

For me, it’s always been about the manifesto, and the ability to make sure that I – as a developer – am doing the best job that I can to build good things for others and for myself.

It’s also a matter of making sure that I’m actively trying to learn from others as well as evangelizing my own practices to others not because I think that I’ve got it figured out, but simply to give back to the developer community.

But apparently, there’s more going on.

How To Document WordPress Projects

April 3, 2013 / Tom / 0 Comments

Earlier this week, I wrote about the challenges of documenting WordPress projects regardless of if they are free or premium.

In the post, I mentioned that another challenge that comes with actually documenting a project is making sure that you’re catering to the various ways that people learn.

First, as a general rule, I think that projects should include:

Source Code Documentation. Free projects should have code comments, premium projects should have code comments, PHPDoc (or similar) style documentation, and API documentation if one is available.
A Manual. Free projects should have a README and potentially a web page, premium projets should have a manual that’s perhaps its own website complete with screenshots and/or videos.

But this raises a second question about WordPress documentation, specifically around premium projects: If people have different styles of learning, that is, some learn better by reading, others better by watching, are we obligated to provide both forms of documentation?

WordPress Documentation For Free and Premium Projects

April 1, 2013 / Tom / 0 Comments

If you spend time maintaining a WordPress project – be it a theme, plugin, or application, and regardless of if it’s free or premium – then you know the challenges that come with writing and maintaining documentation for your project.

Sure, I think many of us who build and maintain projects consider documentation a form of support, but when you ask a customer to define support, you’re more likely to hear about their ability to communicate with someone through a forum or a phone call (depending on your service).

I mean, case in point, when I think about support for my cellular service, I don’t think of documentation of Sprint’s network. I think of talking to a person.

Anyway, all that to say is that over the past few years of working with various types of projects – both on my own and with my team – the trend seems to be that documentation for free projects is expected, but ignored, whereas documentation for premium projects is not only expected, but also read.

But I write this to ask if this is something the rest of you guys have noticed, and, if so, if there isn’t something that can be done to improve this particular situation or it’s simply the nature of the economy. Continue reading