i will be at the web 2.0 expo in nyc this week. I hope to write a few posts about the sessions, and the experience. this is my second time attending this conference, so i’m excited to see what they have in store for us this year. first thoughts, it seems to be smaller than last year, unless everyone decided to show up late. Also no breakfast. just tea and coffee. the theme of the expo is “more with less” so i guess they started off by providing less food.

today i have 5 sessions, and the keynotes. jeff jarvis will be speaking as well as kevin rose. i have high hopes for today, lets see what i learn.
first stop, “darwinism on the web: surviving and thriving in a web 2.0 world.”

right now i regret not bringing a bagel.

Related posts:

1. april fools and technology What is it about April Fools Day and the tech...
2. Using the Basecamp API to Create Project Reports A few months ago I wrote a post describing the...
3. good development teams share information Sometimes its hard to effectively share everything among all members...

Related posts brought to you by Yet Another Related Posts Plugin.

This is a great Article I found on Joel On Software. In this article Joel writes about the concept of the Duct Tape Programmer. This is the programmer who gets things done and doesn’t feel the need to show off their software architect skills by over-engineering software. The Duct Tape Programmer is similar to the fictional developer I called “Jim” in my post A Tale of 2 Developers.

Joel’s rant is truly entertaining and accurate as well. Here’s an example:
“You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.”

I highly value the concept of the practical programmer who writes solid code, regardless of the newest programming fad. Give both articles a read, then come back and tell me your thoughts on the matter.

Related posts:

1. Find the Right Blend of Ideal and Practical Web Development A few weeks ago I wrote that good design is...
2. Iterative Development is Effective Here at SmartMoney, we have been using iterative development techniques...
3. web 2.0 expo @ the javitts center i will be at the web 2.0 expo in nyc...

Related posts brought to you by Yet Another Related Posts Plugin.

A common dilemma of many tech managers and businesses in general is when presented with a business problem, do you build your own software or do you buy? For some companies, this is an easy answer. Some development teams are not equipped with the skills to build a particular tool or product. Other companies just do not have any budget available for the product needed, but do have ample resources to work on development. But for the teams and situations that fall in that middle or gray area, what do you do?

So, how do you decide to build or buy? Through my experiences I have compiled a short list of questions you need to ask yourself as a technology manager.

1. Do I have a budget to buy this product? – If not, the answer has been made for you. You will need to build a product that does the task, or at least can hold you off until there are available funds for purchase. Beware of the trap of building a ‘good enough’ product that then stays long past its shelf life.
2. Can my team build this? – This question has a couple of things to consider. Does your team have the skillets to build the product. Development teams have roles, and sometimes its obvious. For example a web team that builds games is just not going to build a billing system for you. Second, do you have the available resources and time? You may have the talent, but will you be able to set aside the right talent for the time required? They may be needed elsewhere.
3. Does developing in house cost me in other ways? – Once again this speaks to your talent base. Maybe you can put a developer on this application for the time required, but are you missing out on future development opportunities? Is this project so far from their original skills and desires that you will diminish team morale? Less tangible than cost, these are still important to consider.
4. Will the commercial software suit my needs? – My experience has been that many products have a set fee, but then you need to factor in the additional cost of customizations or additions that will suit your business needs. Or you think you can get away with a basic implementation, but soon need to upgrade, incurring additional costs. Or if you are paying for a subscription model, there may come a time when this may not be cost effective anymore.
5. What will the cost be to build? – Again there are a couple of things to look at here. First, how many development hours will a project take? To get a good assessment, you need to be skilled at creating project estimates. If done incorrectly you can end up in a losing proposition. Ask yourself, does your company have a history of feature creep? If so, this project will inevitably take much longer than originally thought. Finally, what is your possible productivity loss? Does putting 2 developers on a six month project keep you from developing a new tool that can be monetized? As Opportunity costs are just as important as accounting cost.
6. Could this be outsourced? – Sometimes the solution is not to build in house, or buy, but rather to have a custom application developed for you. It has been my direct experience that a lot of outsourced code, while possibly cheaper initially has cost more to grow over time. Digging through lines of code to fix bugs or to add a feature ends up wasting a lot of time. If you expect the contracting company to support the product, make sure they have been around awhile, and that you feel confident they will be there in the future. Also make sure their business model allows for incremental updates and support. Many consulting teams work on building and deploying full tools, and are not interested incremental additions.

I have to admit with the increased amount of opensource code in the community and advanced APIs to work with, I tend to build. We can usually find a good opensource product, edit and grow it for our needs, and save a lot of time and headaches. Or we buy a small commercial component that takes care of some aspect of the tool that we could/should not build, then build around that component.

Do you have similar issues? How do you decide whether to build or buy? Maybe you made a decision and wish you had chosen the other? Did I miss a major point in my decision process? I’d love to hear from you. Join the discussion in the comments. We should all learn from each others experiences.

image by msmail

Related posts:

1. Keep Teams Lean Developing effectively starts with the team. Of course projects requirements,...
2. Web Development is a Creative Career Web developers are different breed of technologists. We are increasingly...
3. transparent background Let me give you a little information about where I...

Related posts brought to you by Yet Another Related Posts Plugin.

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

Related posts:

1. Use Project Collaboration Software We use BaseCamp here for managing projects. It is extremely...
2. good development teams share information Sometimes its hard to effectively share everything among all members...
3. How to Effectively Use the Development Community This may seem obvious to most, especially to regular blog...

Related posts brought to you by Yet Another Related Posts Plugin.

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

Related posts:

1. Software: 6 Questions to Ask Yourself When Deciding to Build or Buy A common dilemma of many tech managers and businesses in...
2. Find the Right Blend of Ideal and Practical Web Development A few weeks ago I wrote that good design is...
3. Good Developers Need to be Able to Decompress All good developers need time to decompress. This ability to...

Related posts brought to you by Yet Another Related Posts Plugin.

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

Related posts:

1. Web Development is a Creative Career Web developers are different breed of technologists. We are increasingly...
2. Using the Basecamp API to Create Project Reports A few months ago I wrote a post describing the...
3. Find the Right Blend of Ideal and Practical Web Development A few weeks ago I wrote that good design is...

Related posts brought to you by Yet Another Related Posts Plugin.

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

Related posts:

1. good development teams share information Sometimes its hard to effectively share everything among all members...
2. Software: 6 Questions to Ask Yourself When Deciding to Build or Buy A common dilemma of many tech managers and businesses in...
3. Iterative Development is Effective Here at SmartMoney, we have been using iterative development techniques...

Related posts brought to you by Yet Another Related Posts Plugin.

When I got my first job out of college, I bought a car. It was a new, 1997 Mazda 626. I was excited to finally have some of my own money, so I added all the features I could afford at the time. I added leather, a sun roof, and the ‘luxury package’ which to this day I’m convinced consisted of nicer floor mats. But the coolest feature of all was a standard feature on Mazda’s at the time. The center blower vents (for heating/Air conditioning) on the front dashboard were oscillating.

oscillating vent

The oscillating fan is nothing new, but its not commonly found in cars. Mazda engineers took note and added this to their cars. Why not? It was a simple motor, that with a push of a button allowed the vents to blow air back and forth, efficiently cooling the whole car. We see/use fans every day in our lives, but when passengers got in my car, it always drew comments. That’s how unique it was. It was a minimalist way of providing climate control. Other manufacturers were busy working on heated seats, dual zone cooling/heating, but Mazda took a step back and saw that adding this simple button and motor could provide a lot of benefit for a little investment.

As web designers and developers we need to find that next oscillating fan for the web. The lesson I learned from that fan’s design was that you do not always have to invent a new wheel. Sometimes the next great idea is just a re-using of a current idea. Simple using a common idea in a way that have never been used before can be very effective.

I think the last great web design idea like this may have been the tab. Old methods of navigation were becoming more complicated when amazon pushed the tab navigation. They took a familiar element we are comfortable with in our daily lives (tabs existed in books, file folders, etc…) and applied a graphical representation of it to the web. Tabs existed before Amazon, but in 1998 Amazon really pushed the metaphor and transformed it into a common web interface.

Firefox became a major player in the browser wars partly becasue of their use of multiple tabs. Tabs are now slowly fading form some uses. Firefox says it is looking to abandon the tab in favor of a traditional tree view.

What is the next oscillating fan or tab? We need to constantly look for that complicated or cumbersome element, take a step back and find for the practical solution. They may not all become standards, but sometimes the best ideas don’t always hit. That doesn’t mean we shouldn’t try. After all, I’ve owned 5 cars since that Mazda, and driven countless others and I have never had an oscillating fan in any of them. However every time my car is hot, and i crank up the A/C I fondly remember that feature and wish I had it today.

Related posts:

1. Good Software Design Is Still An Important Art Solid Architecture is a Dying Art When I was in...
2. deployment schedules are not effective Simply put, deploying code on a set schedule is not...
3. Knowing your users will help make effective decisions If you are reading my blog, there is a very...

Related posts brought to you by Yet Another Related Posts Plugin.

I’ve written a guest post on the blog “The 2.0 life: How to Thrive in a Digital World ” entitled: 10 WordPress Plugins Every New Blogger Should Install. Please go check it out, and while you are there look over David’s site. It has a lot of great, practical advise for using web tools and other online survival skills.

Related posts:

1. New Guest Post: The Complete Google Guide to Blogging Tools David Pierce who runs the very useful tech blog “The...
2. Web Tools Tips and Talk #4 As usual, a semi-weekly wrap up of links, tidbits, and...
3. Web Tools Tips and Talk: #7 It’s been another 2 weeks, so here is another wrap...

Related posts brought to you by Yet Another Related Posts Plugin.

This may seem obvious to most, especially to regular blog readers but don’t forget the development community when working on projects. There is a large community of developers and many are willing to share ideas, code, and techniques.

When I am stumped, or simply taxed with a problem that has a common element to it, I have a pretty standard sequence of steps I take to see if I can get help or find a component that someone else created already. Most projects break down into 2 items, common problems and issues specific to your company, environment, etc…

Recently while talking with our operations manager he mentioned he was having problems with an old isapi filter we use to receive and parse incoming customer service tickets. The filter was written over 6 years ago, and the source code is gone. We are lacking a good deploy plan for this filter and we needed to replace it soon. We came up with a very simple solution. Have our mail server dump the incoming .msg files to a secure directory, and write a simple parser to monitor, parse, and insert the tickets into our system.

So I set to work. We are primarily a ColdFusion shop here, however we do write in many other languages. This was a task that would be easily written in ColdFusion and would also run extremely fast. It seemed like the right tool for the job. ColdFusion also has an event monitor that will monitor a directory for new or changed files and trigger code. I have had mixed results with it in the past, but this seemed like a good place to try again. If not, I could simply schedule the script to run at set intervals.

First step, open a msg file and see what we got. Wow, that was going to be a mess to parse. But I had a hunch someone wrote a basic email parser in ColdFusion. If I found one, that would let me spend the time coding the specific pieces of this project related to our environment. So I immediately turned to the community.

Here is a general run down of the steps I take when looking for some code or tips.
- I send an email to my development team. If they already wrote or found similar code, then problem solved.

- Next, I Google my issue. In this case “coldfusion email parser”

- Check a few of the code community sites I have bookmarked in Delicious. In Delicious I keep code and community sites tagged with the language they serve. In this case, fusion authority, adobe, ray camdem’s blog, etc… Whenever I come across a code repository, or good language specific blog, I tag it in delicious. You never know when you’ll need it.

- Twitter: I don’t send a tweet often to ask for help rather, I run a search similar to Google in TweetDeck. I may create one or two searches and let them run. This usually leads me to people who are having similar issues, or possibly written about something I need.

- Finally, if I have time to wait for a response, I go back to some of the code specifics resources I mentioned earlier, and post a question.

One of these usually leads me to the path I need. I have had great success with these methods. Sometimes the module I find is slightly out of date or missing a few key elements I have to add. This is fine, it at least give you a starting point. For example I found a BaseCamp component that worked with their old API. I found it quite easy to add the new API methods and bring it up to date. It provided a nice clean framework to work with. I recommend if you do make changes that the community might find beneficial, please give it back to the community. As soon as I clean up the BaseCamp component, I plan to submit it back to the repository I found it.

This same process can be applied to whole open source apps, you are not limited to simple components when looking for a building block for your project. That’s what makes the development community on the web so useful.

Do you have other techniques, or processes to find help and code you need? Let us know in the comments.

Update 5/7/2009 by Bill: I did eventually find a ColdFusion component that parses emails via my google search. It was on Tom Mollerus’ WebLog. It worked great, and saved me a lot of time. I was able to get this running in a few hours, instead of days.

Related posts:

1. Using the Basecamp API to Create Project Reports A few months ago I wrote a post describing the...
2. good development teams share information Sometimes its hard to effectively share everything among all members...
3. Software: 6 Questions to Ask Yourself When Deciding to Build or Buy A common dilemma of many tech managers and businesses in...

Related posts brought to you by Yet Another Related Posts Plugin.