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. good development teams share information Sometimes its hard to effectively share everything among all members...
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.

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.

The first is called Rework by Jason Fried and David Heinemeier Hansson of 37Signals. Their first book, Getting Real, is a great read for any Software Development team. It will be out on March 9, 2010, and is only $14.96 for the hardcover version. According to the authors “Everything we know about business is in Rework.” If you’ve ever read or heard Jason Fried speak, that means it will definitely contain a lot of great information.

Second, if you read Smashing Magazine, you probably know their long awaited design book, The Smashing Book is also available for pre-order. Right now they are offering their book for 20% off ($23.90 USD), with free shipping. It will be available sooner that Rework (late September 2009). The early reviews are great, and if its anything like their regular posts, it too be be informative, and a must read.

Give these a try. If you happen to have a pre-release copy, or have some other reading recommendations, I’d love to hear in the comments.

Related posts:

1. What’s new? Amazon Bookstore You may have noticed the new addition to the site...
2. Web Tools Tips and Talk: #6 As usual, a semi-weekly wrap up of links, tidbits, and...
3. Web Tools Tips and Talk: #8 It’s been another 2 weeks, so here is another wrap...

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

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.

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 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

• Colabolo Team Collaboration – I do not use this product but I believe strongly in collaboration software, and I also believe in having choices, so here is one you might want to check out.
• ICSI Netalyzr – Having trouble with your internet connection? This tool will help you deduce if you are having a firewall problem, or blocked port, etc…
• pingdom – This site was famous for pinging a site of your choice, and emailing you if it was down. Now they have opened their full site monitoring for free for one site. Great feature at a great deal.

Web Talk/Blogs

• Google changes PageRank flow: Why you should use an iframe in blog comments – Short discussion about Google’s new PageRank algorithm, and how it may affect your comments and nofollow code. If you have comments that allow users to post links, research this and see if it affects you.
• 10 UI Design Patterns You Should Be Paying Attention To – Guide to common User Interface design patterns and a discussion about why they should be important to you. Usability is very important, and this is a pretty detailed read.
• 5 things I wish some people wouldn’t install on their PCs – Fun rant about some of the extras people install on their PCs ultimately slowing them down, or making them unusable. You must know someone who has 20 toolbars installed on their web browser?… or maybe you!
• How to adapt Basecamp to an agile methodology – Case study of an actual development shop using BaseCamp for their SCRUM/Agile team.
• CSS Image Replacement, what’s up Matt? – Article and video discussing using CSS to replace text with images. Discusses why you would want to try this, including SEO benefits.

Web Tips/Resources

• 10+ useful jQuery Plugins for web development – Exactly what it says. A good list for jQuery, tips demos, and code. Always good to have in your code toolbox.
• 7 Firefox Add-ons that make Web Development Easier – I’ve posted similar lists before, but if you don’t have these tools installed, you should. /li>
• 50 Fresh JavaScript Tools That Will Improve Your Workflow – More tools for your toolbox if you are a JavaScript programmer.
• LESS – Leaner CSS – Tutorial and examples for producing cleaner CSS code.
• 35 CSS-Lifesavers For Efficient Web Design – Much more in the lines of CSS tips and tricks.

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

image by seanbonner

Related posts:

1. Web Tools Tips and Talk: #7 It’s been another 2 weeks, so here is another wrap...
2. Web Tools Tips and Talk #4 As usual, a semi-weekly wrap up of links, tidbits, and...
3. Web Tools Tips and Talk: #6 As usual, a semi-weekly wrap up of links, tidbits, and...

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

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. Keep Teams Lean Developing effectively starts with the team. Of course projects requirements,...
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.

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.

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. april fools and technology What is it about April Fools Day and the tech...
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.

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.

Related posts:

1. Web Tools Tips and Talk: #7 It’s been another 2 weeks, so here is another wrap...
2. Web Tools Tips and Talk: #9 It’s been another 2 weeks (plus holiday weekend), so here...
3. Web Tools Tips and Talk: #1 Today, I am going to post a little weekly wrap...

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

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.