A few months ago I wrote a post describing the benefits of using project collaboration software. It helps team members communicate, it avoids information hording, and at any time management can check in and see a project’s progress.

At my job we use BaseCamp. It is a paid product that is extremely powerful and truly helpful. BaseCamp allows you to get projects done, and in my experience does not seem to add a layer of distracting work or complexity. Its features include a wiki, messaging system, a place to store files, and even chat. There is a tool for almost every group’s style. But for my purposes it was lacking some much needed reporting features. This is by design. The creators of BaseCamp felt that instead of developing tons of reports that never to EXACTLY what everyone needs, they would build an API. With the API, you could then in theory build reports that suit your specific needs.

We have a weekly managers meeting where we briefly run down all our open projects and their status. The responsible party can then update and if necessary elaborate briefly on specific items within their project. It is a great meeting to have because it gets all parties from various groups in one room where we quickly keep everyone abreast of the projects being worked on. People in theory can get all the same information from BaseCamp themselves, but reality is this is not always the case. Having the meeting lets us discuss small items with other groups and departments without having to have a longer time consuming meeting.

To create a report for this meeting, I decided to try the BaseCamp API. I figured a quick report that can generate a concise PDF to print out and bring to the meeting will work best. I sat down and used my regular tech community channels to see if anyone has created a BaseCamp API module for ColdFusion. Sure enough, I found baseCamp.cfc from Terrence Ryan. It was exactly what I was looking for. It was written for the older BaseCamp API, so I had to plug in some new methods, but it was a real time saver because it handled all the requests, and parsing of the responses.

I created a report that gathers the list of open projects and their details. First you login with your BaseCamp credentials. Hers is something to take note of. The API code is now logged in as you. If you are creating a report of all the projects to share, then you MUST login as a user who has access to all the projects. It needs to be your account creator, or very high level user. Alternatively, you can simply create a user called reports, and have them automatically added to ALL projects. Then hardcode your API tool to login as this user, and you will have the highest level access to print accurate reports.

Once logged in I grab all the active projects. Then I loop through the project list and make additional API calls to collect the open to-dos and incomplete milestones for each project. Then when I have all my data, I loop through all this information, and format the projects with all their remaining work and due dates.
I also created a longer report that retrieves closed items as well, and adds some more verbose details.

I also had a second need for a report. I have a group of developers that report to me. Each week we go over their assigned tasks and discuss progress. It also gives us a good chance to discuss common problems others may have come across, and share information. The first few weeks after implementing BaseCamp, I was forced to click on every project and then see what was assigned to who, or click on every person and grab their assigned to-do list. The second option was better than the first, but both were little wasteful and time consuming.

Instead, I created a report. First I retrieve all active users from BaseCamp. I display those names as a series of checkboxes. Now any user I csn scroll through the list, and grab the assignments for all the users they checked off at one time. When I loop through the user list, I grab each to-do assigned to them. I can also collect the project information and group the report together by project. So now we can simply review the list of projects and the assignments as a team. It helped keep my meeting organized and productive.

Once I retrieve all the BaseCamp info, parse it, and output it, I have an HTML and PDF view of the reports. Converting output to PDF is extremely simple in ColdFusion, and this gives me great flexibility. Now we can print out a stack of reports when needed, or in the case of my personal group’s meeting, I can simply view it on the computer.

BaseCamp and ColdFusion really paired nicely using the API. I have another report I plan to code soon, involving timesheets. I plan to be able to create timesheets based on project, person, and for various timeframes. I will keep you updated on how it goes.

Does anyone else use the BaseCamp API for their needs? Please share your ideas and experiences in the comments section. I’d love to get new ideas to make BaseCamp even more useful.

image by nataliej

Web developers are different breed of technologists. We are increasingly creative. In my experience this comes from a few factors. On smaller agile teams, developers are asked to work on many roles of a project, and in some cases this includes design. Also unlike traditional software not all web developers are solely computer science majors. They may be designers, or business students who have a passion for the web.

A good web developer is interested in design, performance, user experience – the full range of a tool. They do not code assembly line style. At most shops these days, the same development team that built a tool or product will then maintain it. We live and breath the website and the product. In many cases, the development team is be the group most in tune with the product.

Developers are not always given the credit they deserve from management for being creative. I’ve even seen technical managers who have yet to recognize these facts. They come from an old school mentality, assigning bits and pieces of a web project to their team, having them work in a silo. Their teams are not aware of the bigger business decisions, and feedback is not valued. Their creativity is suppressed, forced to work on implementing mock ups and coding to spec.

Because the actual developer is the one who will work closely with the project, they need to know as much as possible about it, and have the ability to be creative with its individual elements. Like a designer, or writer, developing software is creative, and you need to be passionate about it. It is the developer who should be able to spot the flaw in a design element, and be able to voice their opinion on a replacement. I realize projects have their client requirements, and business elements that are out of our hands. But the creativity of the developer will enable the business requirements to mesh with the real practical aspects of the tool.

Involving developers on a project from its early phases should result in a clean, effective tool that otherwise may not have been achieved by designers and management alone. They can bring a wealth of knowledge to a project both in capabilities and enhancements.

image by jorel314

All good developers need time to decompress. This ability to decompress comes in 2 basic flavors.

The first obvious method would be getting away from the mundane routine of coding. This form of decompression is common to most jobs. Developers like anyone else can benefit from some time away. This can come in small doses, like 20 minutes of web browsing here and there, or in longer form, like a vacation. A lot of developers are able to decompress by surfing the web. This is because the web is a passion for us. Even though we may be are on YouTube watching a video clip, we are also taking in subtle ideas about all the sites we are visiting. “Does this site implement comments in a unique way?” “Would it work for us?” We notice features, navigation choices, GUI elements and are constantly tucking them away into our mental toolbox.

When we find ourselves working on a project where we may be able to implement an earlier idea we saw, we try it. Developers enjoy being creative and applying new concepts and ideas to our work, no matter what the project.

The second way most web developers decompress will come as a bigger surprise to non-technical managers. As I mentioned, web developers are passionate about their trade, and a good developer enjoys working on new ideas. This may mean working on something we have not been assigned to, or re-tweaking code that was written a while ago. Even writing code for personal sites. Google embraces this notion and encourages their employees to use 20% of their workweek for side projects. And it has paid off for Google. Many features you use in Gmail, and Google Calendar each day came from developers own R&D time, and not through committee or assignment. While this may seem like more work, or a distraction to others, this is a huge perk for developers, and results in increased productivity and creativity.

Just like a writer, developers can get a creative block, and need time to step back and come at the problem with a different mindset. Its that creativity that will help your site or application in the long term. If you allow your developers to decompress and in turn build their knowledge base, they will have the clear mind, creativity and skills to tackle their regular projects more efficiently.

photo by Subnet24

It’s been another 2 weeks, so here is another wrap up of the tools, links, and other sites that came across my various readers, etc… It could be a good resource, an interesting blog post, or anything I found useful since the last Web Tools Tips and Talk, #7.

NOTE: If you find these useful please note this is not my full list of links, tools and news. As I come across links for use, I add them all to my Effective Development Delicious.com page.
Sometimes I come across a quick throw away link that I don’t want to wait for the Wrap-Up. Those links I send out as I find them on my Twitter account.
Finally, you can always follow my RSS Feed and check out the Tools Tips and Talk Archive.

Feel free to suggest other links in the comments.

Web Tools

• mobify – There are a few tools out there that do this, but this site creates a slimmed down mobile compatible version of your site. They have free and paid options, but it look like a good place to get your feet wet in the mobile market.
• Notify Mee – Ever have a site you frequent often go down? (ahem…Twitter, Google) When a site you own or use is down, and you want to know when it comes back, simply go here, enter the url, and the email where you’d like to be notified, and they will send you a status when its safe to go back.
• Convert PDF to Word – Upload a PDF, click convert, and you will receive a word Doc (DOC). Simple, free, useful. Sometimes that’s all you need.
• Iconza – Customizable icons for your web site. – Create custom icons to use for free on your site. Tweak the style, size, and color.

Web Talk/Blogs

• DeepTrawl Helps Webmasters Find & Fix Site Errors Quickly, Simply – Quick review of a pretty good tool that traverses/spiders your site looking for typos, broken images and links. You can even schedule it to run at set times and get a report.
• Google Wave: A Complete Guide – I realize Google Wave was announced a few weeks ago, but if you want to weed through the hype, or just missed the discussion Mashable has put together a great guide.
• Monitor Content Copying On Your Site Using Tynt Tracer – Good article discussing a tool that you can setup to check if others are plagiarizing your content. If you are paranoid, or even if you share your content openly and are curious, check out this tool.
• Google Docs gets x’ier with .docx and .xlsx support – Google now supports the x extension that is common in the newest versions of Office. docx, xlsx, etc…
• Adobe service puts browsers side by side – Interesting tool from Adobe called BrowserLab to help you view your site across multiple browsers simultaneously. There are a few ways to do this already, and as a developer/designer, you may already have your favorite. but, Adobe makes good products, so its worth checking out before they start charging for it.

Web Tips/Resources

• EntityCode – A Clear and Quick Reference to HTML Symbol Entities Codes – Simple HTML reference for those quirky HTML codes you sometimes need. Like registered trademark, copyright, dollar and currency signs, etc… Bookmark this one, you’ll need it someday.
• 10 HTML Tag Crimes You Really Shouldn’t Commit – Tutorial I found from twitter.com/KISSmetrics reviewing some simple HTML best practices. Or rather bad practices to avoid.
• OOPhoto – Another Attempt At Learning Object Oriented Programming (OOP) In ColdFusion – Ben nadel writes great instructional programming series. This one focuses on writing a photo gallery on ColdFusion, with a focus on Object Oriented Design. If any of these facts interest you, check it out.
• Useful checks to test for XSS attacks on your ColdFusion site – Quick post that discusses how to check if your ColdFusion site is vulnerable to XSS (Cross Site Scripting Attacks)
• How To Change Default Webpage Source Editor Of Browsers – Want to view browser source in Notepad, or notepad++? This quick tutorial tells you how to change the default viewer for various popular browsers.
• Effective Strategy To Estimate Time For Your Design Projects – I wrote a post about estimating resources and projects this week. Coincidently Smashing Magazine also ran a really good article about this topic. Its a very good read, with a lot of details.

Enjoy, and have a good weekend.
Post any good resources or links you use in the comments.

Coming up with accurate time and resource estimate is one of the toughest skills of a good tech manager. It is an under appreciated skill, but vital to a project’s success. In the ‘real world’ this one area requires many skills. It is necessary to have a deep knowledge of the project and technologies to be used, familiarity and confidence with your available resources as well as an intimate knowledge of the ‘outside’ forces. Outside forces on a project include other projects, vacation and resource availability, and finally all the stake-holders in the project. This could be your client, your boss, or perhaps another group in your company. This piece of the puzzle is usually the largest wild card when making an estimate.

Hopefully, you are working on a small, manageable project or feature. As I mentioned in a previous post, no web project should take 9 months to a year of development. Delays are one thing, but if the project plan calls for over 6 months of specs, development, and QA, the project should be broken down to more digestible pieces immediately.

I speak from experience here. In 2008, we completely redesigned our website. We looked to change both the front-end and back-end infrastructure and add every feature we could conjure up, but when the estimates rose into the 9-12 month range we scaled back the project. This reduced risk, and allowed us to provide an accurate estimate to the project’s stakeholders.

After 8+ years of creating estimates for both internal and client based projects, I have a basic formula. This formula works for billable or developer hours. This is not a ‘Time to Completion’ estimate. Those estimates require knowledge of the company, other projects on the development queue, and resource availability.

Here is the ‘secret sauce’:
When I have a project, I break it out into tangible subsections. Design, HTML/CSS front-end work, back-end work, middle tier, and database interaction. For each of these areas, there are questions that every manager must ask. These will be specific to your business and type of work. An example could be “will this project require third party data, or a registered user database? Do we need to put this particular feature behind a login? Or what technologies are we using or need to interact with?”. Knowing the right questions to ask comes with experience.

At this point I take the resulting pieces, and come up with hourly estimates.
Any feature or additional piece of functionality adds complexity to the whole project. They do not stand on their own. Let me explain. Say a particular widget takes 2-4 hours to develop on its own. And a poll or survey takes another 4 hours. Imagine a project comes across your plate that needs a poll, and also links to this ‘widget’. Simple addition would say this is 4-6 hours, but you know linking these 2 technologies will take more development, and add more complexities to maintain. Maybe it affects another poll or feature you deployed last week, and now that too has to be incorporated into this new poll+widget idea. So in reality, this new idea might take 8-10 hours to complete.

You can easily see how the owner of this idea will not understand the additional hours needed if they are not technical or involved in the big picture. Selling these additional costs is another difficult part of the reality or practical development. Its very hard to explain the nuances of the development processes to the non-technical parties involved.

Because of added and unforeseen complexities like these, I use the following hourly increments when creating estimates.

All items take the following time (measured in developer-hours).

• 2, 4, 6, 8, 12, 16: These increments work for 80% of feature additions.
• Anything over 16 hours proceeds in increments of 8 until 40 hours. (24, 32, 40)
• After 40 hours (1 week of one developers time), start to increase by 12.

(This is because anything over a week now has a higher probability of being affected by outside sources now. I can easily shield any developer on my team from outside distractions for 1 week, but its impossible to push off a person entirely after that. You may absolutely need them for something else with a higher priority or deadline.)

• After crossing 60 hours, I increase by 16 hours at a time.
• We usually stop at 120 hours.

Very few projects get estimates past 80 hours anymore, but its not impossible. After 120 hours, we break the project into smaller, more digestible pieces of 80 hrs and under. I recently estimated a very large project at 300 developer hours, but it was really 3-4 smaller projects of 60-100 hours each. With practice you will find natural ‘breaks’ in a project for estimates. Maybe its database, back-end, and front-end. Etc…

I have spoken about realistically breaking down into 6 month turnarounds, which is usually a maximum of 120 hours of developer time. You will definitely have to tweak this for the way things work at your company, but the hourly incremental formula has worked for me for years, and always provides accurate billable estimates. Also don’t forget to add in a little padding for 3rd party projects, where you do not control all the project deliverables, and you shouldn’t get burned by a low ball estimate when it comes time to bill.

You may also need to estimate design and project management into your estimates depending on where you work. This method concentrates on the area I have the most expertise in, Web Development.

None of this is a science, rather it is an art, and there are no guarantees projects will come in under budget using these methods. This is particularly hard for us to come to grip with in the technology field. We like accuracy and concrete formulas by nature. However, I find these guidelines have provided fairly accurate estimates for me for years. Remember to keep records and compare your actual time with your estimates, and you will be able to achieve more accuracy over time.

Does anyone else use a similar or perhaps a completely different process for estimating developer time? I’d love to hear about it and discuss.

image by HikingArtist.com

You may have noticed the new addition to the site recently. I have added an Amazon Bookstore to my header navigation and to the right column of the site. While I do make a small percentage off of any sales, this is also an opportunity to showcase books I have read and found useful to my coding and management style. I have read most of the books here, and if i didn’t they are in my Amazon Wishlist for future reading.

A lot of the ideas for my blog are formulated from my experiences and findings. Many are based on things I have read and various discussions with peers. Like i said in my early posts, I do read and keep up to date with many of the latest methodologies, but I adapt and try to fit them into the reality of working in a corporate environment. I do not blindly chase and accept all the latest trends.

I would like to briefly discuss some of the books I’ve chosen to showcase in my store and why they would be of use to you. I do not read a lot of code books, many of them are out of date before they are published. The web is the perfect resource for changing data. But for timeless concepts, book are still important to have on hand. And if you are truly anti print, get a Kindle.

Web Design and Development

Don’t Make Me Think by Steve Krug. This is one of the best all around web design books. Steve is a fan of simple usability techniques. He wants to keep things easy and clean. He is a huge advocate of usability testing. He makes it clear how useful usability tests are and how easy and cheap they are to conduct. Since passing this around my group we conduct usability tests on a regular basis. The book is a very fast read, and if you read one book on my list, make it this one.

Designing the Obvious: A Common Sense Approach to Web Application Design By Robert Hoekman Jr. This book makes a good companion to Don’t Make Me Think. It also talks about simple, clean design and how the user experience should be the most important factor when creating web apps. A lot of my Knowing your users will help make effective decisions post, is based on some of these ideas.

Always Be Testing: The Complete Guide to Google Website Optimizer By Bryan Eisenberg, John Quarto-vonTivadar A good intro the A/B and multivariate testing. It focuses on Google Website Analyzer specifically but many of the concepts can be applied to any testing tool such as Omniture Offermatica. My first 2 books talk a lot about the importance of testing but does not go into specifics on how to achieve this. This book fills in a lot of the gaps.

Web Analytics: An Hour a Day By Avinash Kaushik Avinash is widely considered one of the top web analytics gurus and he focuses on Google Analytics. If you use Google Anlytics, then this book is very practical. Google makes setting up their analytics package so easy, but sometimes it is hard to extract exactly what you need from their tool. Avenish explains concepts like conversions and also explains their importance. Google Analytics help is so hard to come by, this book really provides a strong basis for working with the tool.

Getting Real: The smarter, faster, easier way to build a successful web application By 37signals. This book is really a composite of essays written by 37Signals. It gives you a window into their world of Getting Real, the philosophy upon which their company runs. I’ve often said my feelings of effective development are basically a practical spin on a lot of Getting Real. Getting Real is sometimes too ideal, but you can’t formulate what works for you without first reading the original

Team Management

Maverick: The Success Story Behind the World’s Most Unusual Workplace By Ricardo Semler This is a wonderful, cheap and fast read. This book is very entertaining, and the story is very unique. It explains a lot of groundbreaking management techniques that Ricardo Semler began in his company in Brazil years ago. Many management techniques have since been adapted from his still unique ideas. Even if you do not run your company you will benefit from this read. I have found many little areas where I try to work in adaptions of his leadership techniques.

Why Work Sucks and How to Fix It: No Schedules, No Meetings, No Joke–the Simple Change That Can Make Your Job Terrific By Cali Ressler, Jody Thompson
Similiar to Maverick, it applies groundbreaking but extremely practical ideas for workplace management. Once again, read it and formulate what is effective for you. These are not bibles, rather they are written to get you thinking of how it is applicable to your unique workplace.

Those are the books i have read recently and felt inspired to share with you. I have added other groups in my Amazon store that I have either placed in my wishlist or feel passionate about.

The project management group consists of books written for project management in an agile environment. traditional project management is dying. I plan to write a post shortly about how we are able to manage projects in a pseudo agile workplace.

The business and marketing section consists of 2 book I plan to read soon. I have read good reviews of both. Basic marketing is a necessary skill for today’s developers and managers. Traditionally it is not taught in computer science curriculum. More often we are put in positions where we need to market our teams and the products we build. As projects get more agile, and do not come with hundred page accompanying docs, management needs to be sold on features and iterative changes. This is where marketing yourself and your group comes into play.

The web books from Amazon is simply a window into Amazon’s web development genre. It is broad but you may find it useful for finding some good tech books.

Finally I am becoming a huge fan of netbooks. They will not replace you primary computer, but now that specialized devices like the Kindle and iPhone are becoming so popular, I suggest you look to a netbook instead. Rather than getting a device that is just like a computer, why not actually buy an actual computer. They are small, relatively powerful, and cheap. I have a Dell Mini 9, and love it.

Photo by IntDev