Iconography of the Day: Cowboys & Aliens marks Harrison Ford’s 40th credited big-screen appearance.
The National Post‘s Steve Murray (AKA Chip Zdarsky AKA Todd Diamond) celebrates this extra-large (get it?) accomplishment with “Forty Fords” — an illustrated “look back at everyone’s favourite acting chameleon.”
[nationalpost / thanks chris!]
Taking on a large project can be both exciting and intimidating, particularly if you’re a solo developer. Big builds can be a lot of fun and serve as great learning experiences. At the same time, you have to keep the project moving forward, or risk missed deadlines and burnout.
Below are some tips to help you stay organized and productive, whether you’re working individually or as a team.
When dealing with clients, issues like scope creep, late payments and deadlines are always a concern. And what may seem obvious to you may not be clear to your client. To avoid hurt feelings, delays and financial troubles, your first priority should be establishing a thorough, firm, but fair written contract.
A good contract protects both you and your client. In addition to general terms and conditions, your contract should contain specifics about the project: payment schedules, due dates, deadlines (and consequences for missing those deadlines), cancellation policies, guidelines regarding intellectual property and project scope. You can find many sample contracts on the web, but there’s no substitute for consulting with an attorney. When dealing with the safety of your business and your livelihood, the expense is justifiable, and should be calculated in your business overhead.
One of the required supplements to your contract should always be a project road map. It should outline all of the project features as thoroughly as possible, and establish the general plan for project progression, from research all the way through deployment.
To start, write out all of the features in outline format. It helps to break them down into groups, such as “Account Administration Features” and “Inventory Control Features,” for example. Keep refining the outline until you’ve defined exactly what is expected and what needs to be developed.
Next, break the project down into different phases, such as research, design, development, testing and deployment. For each phase, state its goals clearly, and define where the project should be when the phase is completed. Have your client sign off on the phases, and include this document with your contract. You may want to make a second copy of this road map to include more technical details, such as technologies to employ and methods to implement each feature — but don’t change the scope unless your client signs off on the changes.
Whether you’re working alone or with a team, taking the time to establish a style guide for your project will help you maintain consistency throughout. Furthermore, when the project needs updating six months from now, you’ll be glad you made the effort.
There are two types of style guides you should consider: a visual guide and a coding guide. Keep in mind that either or both may apply to the project. The visual style guide should contain information regarding fonts, colors, branding and any other notes on visual appearance. You should also include a few examples of common elements, such as headers, forms, body content, sidebars and menus. While you may never need to go into such detail, the Skype Brand Book is a great example. The guide provides a great presentation to your client, a tool to help them understand how the project will ultimately look and feel. Review the established style with the client (mood boards are great for this purpose), and have them sign off on the look. Refer back to the visual style guide often during your own work to make sure you’re adhering to the set guidelines.
A programming style guide needn’t be project-specific (unless you’re working with a new team that has already established a style different from your own). It may be as simple as following an existing style guide, such as the Zend style guide. You don’t need to start from scratch here, but you need to be consistent. Having a clear set of guidelines will help any developers who may come on board later.
When developing a new project, particularly one that’s interesting and exciting, people have the temptation to dive right in and get to work. An initial lack of proper research and planning can have detrimental effects, especially for larger projects. Take the proper initial steps and spend time researching, diagramming, reading through source code and organizing your thoughts. It will end up saving you time and money down the road.
The same applies to testing your code. It will spare you the tedious and often embarrassing problems of code rewrites, because the only thing worse than having your code fail during a demo is having it fail in production. Testing code and debugging shouldn’t be afterthoughts, so work both into your project estimate and timeline. There are a lot of automated testing suites out there today — everything from PHP and JavaScript to Ruby and Python, and countless other languages. It’s a good idea to learn at least one for each language you plan to use. Don’t forget to have real users navigate your software too. You and your client should both spend time actually using the site you’ve developed before going live.
If you’re like most developers, you cringe at the thought of writing documentation. Taking the time to document something, especially when it seems clear at the time of creation, feels like a waste of valuable time. However, years from now those thousands of lines of source code may not make nearly as much sense.
Furthermore, programming styles and skill evolve over time, which can make old code hard to dive back into. So take time to document your code as you go. Make it as intuitive as possible by using descriptive names and logical progression. As a good rule of thumb, you should never need to document what something does, but make notes in your code that explain a feature’s purpose and function. Also note any dependencies that it either relies on or creates. Stopping at the end of each new feature and taking the time to draft some end-user documentation is a good idea as well. This will make it much easier to train your client on the software, and will also serve as a good way to catch any usability issues or features that were accidentally omitted.
This should almost go without saying, but many solo developers don’t use version control for their projects. For a large project, this simply isn’t an option. A good VCS (whether you choose SVN, Git, Mercurial or some other system) virtually eliminates the possibility of accidentally deleting or overwriting code.
In addition to providing an invaluable safety net, commit logs also help you track your progress. And the ability to branch, fork, and merge your code gives you the flexibility to experiment with different methods of feature implementation. You can also refine and fine-tune your software’s performance without the risk of breaking existing code. Finally, it simplifies remote backup and deployment to testing and production environments. These days, version control should be considered an essential part of your development, particularly if you collaborate with other individuals.
Whether you prefer to use a laptop or a spiral-bound notebook, take notes when you meet with your client and other collaborators. Otherwise, you may not retain that minor detail discussed during the meeting as effectively. Good note-taking demonstrates to your clients that you’re attentive, interested and dedicated to providing them with good service. It ensures you don’t forget the little details, and it also saves you the embarrassment of having to go back to the client for clarification. It sounds simple, but one minor modification that went forgotten or overlooked could mean major changes in code or functionality. Save yourself the headache, stress and humiliation and learn to write everything down.
As with thorough note-taking, keeping assets organized is another important step toward streamlining your project work flow. You may even consider a separate version control repository for project assets that don’t belong in the finished code base. Your client will likely send you a lot of files, content, artwork and emails containing feedback and requests for modifications and new features. Often, they’ll send more than one version of those files or requests.
Think about putting these assets into version control or some well-defined project management software. It can go a long way toward helping you keep information organized. Sending the wrong file or hunting through hundreds of emails not only slows you down and introduces the likelihood of errors, it makes you look unprofessional.
Due dates may often be established when outlining the project and its contract, but if this isn’t something you’re already doing, or if your current system isn’t working as well as you would like, it’s definitely worth the attention. Large projects tend to have a lot of dependencies, and missing one deadline can often put an entire project behind schedule. Mark due dates on your calendar and discipline yourself to stick to them.
Due dates aren’t just for you, either. It’s not at all unreasonable to give your client due dates for various deliverables, such as content and branding, and to set fixed periods of time for reviewing and approving assets. Clearly define due dates for all parties, and furthermore, address the consequences of unmet deadlines. As with negotiating a contract and drafting the project outline, always try to be fair, but don’t be afraid to be firm. Your client will respect you for it, and your reputation and career depend on it.
Images courtesy of Flickr, ZedZAP .. gone camping, justonlysteve
More About: code, contract, design, dev, developement, MARKETING, programming, project, style, web development series
For more Dev & Design coverage:
Rackspace recently published a nice infographic on the evolution of programming languages. It starts with FORTRAN and COBOL and runs through Ruby on Rails (which, yes, is a framework and not a language).
Unfortunately, it omits such influential languages as Lisp, ALGOL 60 and Smalltalk. But including every important language ever would make for a pretty long infographic.
Sponsor
The popularity stats at the end are apparently sourced from the oft criticized TIOBE. You can find the full sized graphic and bibliography here.
If you’re a comic book fan, you’ll love the trivia-laden stroll through Marvel’s history laid out in this infographic. Michael Jackson almost bought Marvel? Sauron was created to get around a ban on werewolves?
Marvel [Daily Infographic]
 |  |  |
| How to Make Free Android or iPhone Ringtones From Any Youtube Video | How to Configure Your Router for Network Wide URL Logging | How to Make Photos Look Like Pencil Drawings in About One Minute |
