Again at my new blog, I have a post about the importance of working with a developer when planning your site, and continuing to work with them throughout the life of your site.
Month: July 2012
Work with Developers
While not up to the level of this hoary fun fact, you can take the title of this piece in multiple ways. Here, I mean two of them.
Work with developers
There are a lot of people who are “consultants” or “strategists” who’ve never built a working website, beyond possibly a simple HTML site in the 90s or configuring a blog in the last decade. That doesn’t mean these people have nothing to contribute; if they’re smart, they’ve observed what’s worked and what hasn’t, have good insights, and can relate to your organization’s problems in a way that helps bridge the gap. However, it’s rare that they have as intuitive a sense of how a potential solution will look in software, what level of effort it will require, or what alternatives might solve the problem as well.
Nothing’s more frustrating than talking through a problem, imagining a solution, and then being told three days later that it isn’t within your budget or, worse, being told at the end of the process that it’s going to require several more development cycles to complete when you’re already out of budget. A strategist or consultant who has built lots of websites similar to the one you’re considering will have that sense and be able to steer you to solutions or at least identify that more research is needed.
None of this, of course, means that just any developer will do. You will want someone who is good at bridging that gap between engineers and people who need their services. If they don’t have experience or expertise in your sector, then be prepared to educate them on the wherefores and whys of what you do and the special challenges you face that other organizations don’t. This, by the way, is a good role for those non-technical strategists or consultants: if they have expertise or experience in your sector, they can help bridge that gap to a developer who doesn’t but is good at working with customers.
Fortunately, most successful web development firms are founded by and staffed with technical types who are filling other roles but who started out as engineers. Likewise most successful independent developers are successful because they’re good at working with people to identify solutions that fit within their budget. This may not be true for agencies who “also” do web development, so if it isn’t obvious, look for technical experience in the resume of anyone proposed as your strategist and ask them about that experience before hiring them.
Work with developers
Planning a site isn’t something that happens only before the site is built. In fact, some argue that writing software basically is writing a design document in detail. [PDF] Once you’re working with someone who has stayed up late sweating out lots of different web development problems, you have someone who can work with you to figure out a way to address your problem that fits your budget, rather than simply taking orders and coming back to you late and over budget.
Additionally, software projects are notorious for having requirements change or receiving feedback that changes your initial assumptions—which then changes the requirements. So when you’re working collaboratively with the developer instead of handing them a specification, you have someone who can help you think through alternatives when those inevitable changes occur.
It takes a team
None of this is to say that web developers are the only people who should be involved in building your site or application: rare is the developer who also understands strategy, design, and user experience equally well as they understand code. But the stereotype of the socially inept engineer who can’t talk with anyone has left technical people out of the planning, and planning a site never stops. So make sure they’re in the room, have a voice, and are working with you to balance your needs, your budget, and their technology.
Single Sign-on (SSO): a budget buster
At my new blog, I look at how trying to tie all your applications together with one login (Single Sign-on (SSO)) is usually a complete waste of money and look at alternatives.
$ing£e $ign On
One of the biggest causes of heartburn I’ve seen on projects is when organizations want single sign on.
It should be simple!
On the surface, it’s simple, right? Why remember a bunch of passwords, when you can just tie those systems together and have them use the same login across them. After all, you’re the same person, so why should you have to identify yourself differently to each program you use to do your work?
In practice, especially in the nonprofit world, many applications date from a time before a ubiquitous internet pushed applications from your local computer to a web server. Since most people would ever only need to access that application and a few others, and often identity was tied to a computer rather than a person, there really wasn’t a reason to build in a security nightmare of letting other applications access your users or tell you who someone was.
Additionally, lots of those applications date from the time when everyone tried to be everything to your organization. Some later applications (*cough*Convio*cough*) still think that way, and try to have a “component” to do each thing you want done, rather than being the best of breed in one area and letting other companies handle other aspects of your operation.
Additionally, there’s no good standard for sharing identities—your login—across application. Sure, there are plenty of standards, but no good ones. Some require you to go to a trusted third party website to authenticate, and some are enterprise-y schemas that aren’t implemented the same way across systems.
And guess what? There isn’t a standard that everybody supports. So almost no matter what scheme you try to use, no two popular systems likely use them. Most open source systems allow you to “hook in” to their login and put custom code in its place, but the more custom code that has to be written, the more development time, testing, and room for general bugginess—and it opens up new vectors for hackers.
So what do you do?
Fortunately, there’s a pretty easy solution: if your applications are web-based, every modern browser supports a “remember my password” function. It’s free, it’s already there, and you probably use it at home. I logged into hundreds of websites regularly when I was consulting, and I just had the browser remember the passwords. Sure, there’s that extra step of going through a login screen, but it turns out most shared identity systems actually make you go through a username screen, just without a password. Since the browser remembers it for you, you’ve lost zero time.
If for some reason that doesn’t work for you, then look into password managers. They’re great applications, and if you use Mac OS X, it’s built into the operating system. (Look for “Keychain”—it even syncs over iCloud!) Here’s a review of five different systems, most of which work cross-platform.
Yeah, but I want it! (And a flying magic unicorn pony.)
Be prepared to add 20%, minimum, to the cost of your project.
That’s a lot of features you’re giving up to save yourself a few seconds of using a password manager each day. Assuming your project is $120,000 and you have 20 users, each of whom (at an extreme) spends 30 seconds per workday dealing with password managers, that’s paying $20,000 to save you the equivalent of one person doing a week’s work. Unless your employees cost you $500 an hour, almost anything you do will get you more value for your budget.
Save the money, and just train yourself to click “Yes, remember this password,” when that dialog pops up.
New Venture: Helping organizations work with web devs
On the side, I’ve started a new blog and consulting practice. Since I’ve worked as a web dev but have business, strategy, and policy experience, I’m in a good position to help organizations help themselves when they contract with web developers and web development shops.
So if you need some help figuring out how to get the best results out of your next web engagement, contact me.
Hello World: I’m here to help you understand web developers
I’ve been a web developer for a long time. An eternity in the web world: 15 years. I’ve also spent all but a year of that time consulting, usually for nonprofits and government. I’ve worked in-house and in an agency. I’ve probably worked with a hundred or so organizations in various capacities, from basic development to strategic advice to multi-tier applications. I’ve been around the block, in other words.
And in that time I’ve seen most of the mistakes web developers and web agencies can make, but I’ve also seen a lot of cases where a lack of understanding between the two has cost budget, delayed or killed projects, and left everyone with a bitter taste in their mouths.
So why am I qualified to bridge this gap? I was actually trained in international relations and understand the environment of nonprofits and government as well as business and web development. And since so much of the conflict is needless, I want to put myself in a position to be a trusted advisor without selling anything beyond my advice.
If you’re about to engage in a redesign, create a project site, or want to figure out how to use the web effectively to get your message out and engage people, the content here will help you avoid learning these lessons the hard way. And if you want personalized help or for me to come and talk to your organization, let me know.
Wednesday Afternoon Kodi Blogging
By request, Kodi discovers the lake. And splashes at the edge and proceeds to roll around in the muck instead.
CMS, Framework, or DIY: How do you choose?
Web developers and web development companies frequently start each project as if they only things that need to be built require merely different types of nails, and luckily they have a hammer. In fact, they often call themselves “Drupal developers” or “Ruby on Rails developers” rather than Web developers (or software engineers). The opposite also happens, where someone will approach each project as a custom, ground-up web development project. Wars inevitably break out over what platform is “best” for web development. Purists slag framework devs as lazy and imprecise, framework devs slag CMS developers the same way and purists as wheel-reinventors, and CMS devs slag the others as wheel-reinventors and one another as using an “inferior” CMS.
The best developers I know may have favorite tools, but they either put them aside when they’re the wrong tool or pass on inappropriate jobs in favor of projects that match their preferred development niche. Others simply choose the best tool for the task at hand…but that choice can be the first point of blank page syndrome. What follows are questions to ask yourself and how the answers can influence your choice.
What does the client expect?
Every project has a client. Even if that client is yourself or your boss, let alone someone who is paying you for a bespoke web application. Sometimes they have particular ideas, for good or ill. You can try to argue the choice if you think it’s wrong, but ultimately the person paying will have to approve your choice. Obviously if you’re adding on to a Drupal website, you have to make a pretty strong argument that Zend Framework is the right choice. (Though I’ve seen it done.) In the nonprofit sector, for example, there’s a huge preference in favor of Drupal for anything larger than a basic site or blog. A previous company I worked for tried to argue for a different solution, but ultimately had to deliver what clients wanted as many dropped non-Drupal proposals immediately.
What is the legacy technology stack?
It’s been a decade since the average web development project was “helping an organization finally get on the web.” Even new projects in existing organizations are often project-specific websites in addition to the main organizational site. Sometimes organizations have a large infrastructure dedicated to serving other sites. While in general I’m not a fan of people hosting their own sites and often throw out the sunk cost fallacy in arguments, sometimes it’s easier to reuse existing equipment and experience than introduce a new technology stack. So if an organization has a ton of ExpressionEngine sites, asking them to host a Drupal site may not end well if they’re not familiar with keeping Drupal up to date or staff need a lot of handholding to use a new system.
What does the end product mostly do?
Even if the excitement is around a small application on the site, if the bulk of the requested functionality revolves around managing web pages, articles, and comments, then starting with a CMS may be the responsible thing to do. While every CMS entails design tradeoffs and limitations that often drive experienced developers nuts, I’d rather focus my development effort on getting that one web application right and adapting it to the CMS’s module structure and API than rebuilding page, menu, login, admin, and comment functionality again.
What will the application do over time?
Small organization sites may live forever as a basic set of rarely-updated pages. Most restaurant pages only need to update menus and maybe an events calendar. Intranet applications will tend to get added on to and fixed over time but never have a vast number of users. And that social networking site may become Facebook.
While lots of startups jumped on the Ruby on Rails bandwagon after Twitter took off, Twitter ended up rewriting most of their site as they scaled. The tradeoff was a quick minimum viable product versus a platform they could easily grow as time went on, and there was a period in which had another service arisen on a more reliable stack, we’d remember Twitter the way we remember Friendster. At mojoLive, we looked seriously at Zend Framework since it was built to have any individual component thrown out for a custom replacement as was needed for scaling, but ultimately it didn’t help us do enough of the hard things easily and would require a significant learning curve to build something we knew was going to be thrown away. Building a custom app based on some code Eli had lying around with a minimal MVC layer didn’t slow us down appreciably over picking up a new framework.
Startups and large enterprise applications also have developers working on them all the time, unlike small organization sites. In the latter case, a well-known CMS is going to be a lot easier than a custom-built CMS for someone to come along and update when you’ve gone on to bigger and better things.
What do you know?
Unless you’re doing a project specifically to learn a technology (and it’s either personal or the client has approved you taking on something you don’t already know because they’re awesome, desperate, or you gave them a big discount), it’s rarely a good idea to start with something you don’t know. Even if you know PHP inside and out, Zend Framework and Drupal have layers of best practices specific to those environments that take time to learn. And jumping from an object-oriented or imperative language to a functional language is…challenging, to say the least.
When is the project due? What’s the budget?
There’s no point in building a new CMS that’s going to take over the world just to churn out a 3-page site due end of the week. The less time you have, the more you’re going to want built for you. Similarly, you’re going to want to stick closer to what you know.
TL; DR
There is, unfortunately, a lot of overlap in the capabilities of systems. Obviously you can ground-up write any app in existence, if you have enough time and budget. (And skill and experience and…) That being said, you can make Drupal into a 300+ mini site system with overlapping permissions, 12,000+ shared users, and single signon with Salesforce. It wasn’t my first choice, but the mix of familiarity, budget, and client expectations led me there. That being said, it was a huge pain and the gains of the CMS components were probably overwhelmed by trying to shove a very idiosyncratic enterprise-level set of requirements onto a CMS whose sweet spot is rapidly building middling complexity content management sites with community features.
In general, though, sites that primarily content belong to CMSes, sites that are primarily web apps with tighter deadlines or without huge growth requirements are better off with frameworks, and sites that are going to be constantly developed and scale rapidly are likely best ground-up. You can find exceptions to all of these, and there are clever people who’ve built simple ground-up CMS apps and made WordPress run massively complex sites, but that rule of thumb should keep your next project from being a cautionary tale of trying to hammer in screws.
Sandy Smith 