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 Development is a Creative Career Web developers are different breed of technologists. We are increasingly...

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.

A few weeks ago I wrote that good design is a dying but important art. While I do believe that is true, there is also too much of a good thing. Sometimes you can get too caught up in the ‘ideal’, worrying and designing things to be perfect. Deciding what is the right blend of ideal and pragmatic is also an art, and in my opinion one of the most important tasks of a developer or manager.

I have worked on many web projects in many roles. I have been a junior developer, senior developer, and the technical architect where I was not going to do any of the actual coding. Whether developing or designing you are constantly faced with a challenge. Developing the ideal or textbook vs a real or pragmatic approach. My philosophy is to lean towards pragmatic. I believe you should be versed in the textbook methodologies as they are very useful and it is wasteful to reinvent the wheel. You need them in your arsenal to apply when necessary. In the end if we have a production quality piece of code that runs with minimal issues, and can be updated, do I really care if my developers used the ‘correct’ factory or design methodologies for the project? I do not. The correct methodology for me is the one that works and gets the job done on time. Again I want to re-iterate that does not mean I believe in sloppy, spaghetti code. I certainly do not. But I definitely value function over form.

A lot of these development styles are fads. Yes things are constantly being improved, but just because something is new, its not always better. Extreme programming leads the way to another style. Configuration and initialization files were all the rage for years, now abandoned in favor of self describing code. Developers could sit and debate the correct factory to use for a job in the same time I could code the whole project.

We are builders, we take a tool (programming language) and we create product. So
just like there are many ways to build a house, the same holds true for web development. Sure some methods are better than others, but if your team is talented enough most of the decisions they make will be good enough for the job.

You need to build the product for as long as its lifespan. Not every house is built to stand 500 years, and neither is code. Just like a builder in Montana does not build a house to be hurricane proof you should not build for problems you don’t have. You should build code in a way that it can be modified and extended should the need arise. But if you are building a niche craft site with only a handful of users and 5 products to sell, do not waste time designing to be the next Amazon.com. When you add more products you can worry if your shopping cart class has the extendability to grow, just get the code live.

My advice is if you are a senior tech lead or manager you should keep up with the new methodologies that are making a wave. But don’t chase them all, and don’t distract your development team with all of them. They have a lot of code to write and having them chase the next development fad is not in anyone’s best interest. As a manager you should know when to push your developers towards a certain technology, and where to adapt it to fit your team’s and company’s needs. You may spend 2 years designing the perfect framework for a job but that is just not practical, and in most companies it will not be tolerated. Most senior managers do not care about how it’s done, just that it was completed under budget and on time. As a tech manager your role is to find the most effective blend of ideal and practical to keep management happy and your developers skill set ready to tackle the next project.

Related posts:

1. Hello world! Welcome! This is my first post, so let me introduce...
2. Software: 6 Questions to Ask Yourself When Deciding to Build or Buy A common dilemma of many tech managers and businesses in...
3. product versus project manager For years, SmartMoney had project manager(s).  This was more of...

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

Simply put, deploying code on a set schedule is not practical or effective. Unless you are a bank or medical facility, you just do not have to adhere to such a strict release and deployment schedule. I have had the luxury of working on sites where we do not employ deployment schedules. There are times over the last 10 years where not having a schedule has burned us slightly. At those times, we tried to be more rigid, but inevitably we would go back to our old ways with looser deployment procedures. Now that I am running the development team, I consider the ‘old ways’ the correct way. Over the past 10 years there have been many more times where having an agile style of development and deployment has helped. The benefits far outweigh the few negative experiences we have had.

I have worked with outside groups on projects where the other development team had to wait a full week to fix a bug. Not a critical bug, but a bug nonetheless. Any bug is major to the user that it affects them adversely. If you are a user and you see an issue, even a minor one, do you care that management has deemed the bug minor and the development team is not able to fix it until next Tuesday @ 7:30 PM? No you don’t care. All your users know is that something is broken, or looks wrong, and has stayed that way for 7 days. By that time, you may have turned off users to your site, or at least given them the impression you are incompetent or uninterested in the quality of your site.

Many times management does not like a loose deployment schedule because their sites are complex. Its safer to only deploy code once a week, and in large batches. But this too has its downfall. Many times so many changes queue up that the deploy now becomes very complex. Deploying, testing and monitoring 10 distinct feature/code changes is not an easy task. Other times minor changes get pushed off the deploy sheet, and end up waiting yet another week (or more) before they are pushed live.

Trust me, the site I work on on is extremely complex. There is content, data from third parties, and full featured tools for research. These are only a few pieces of the large puzzle that is our site. If we are able to keep this all running with a lean team of developers and with a loose deployment schedule, your site can too. I’m not condoning a gunslinger attitude or setting code loose into the world at will. You need to test, and trust your developers. You need to monitor changes, and test after its been deployed. You need to check your web and error logs and continue to use software to share information, and discuss changes. Basically, you need to be very diligent about what you put on your live website. But you do not need to wait until a Wednesday night to send code live. Send code live when it is ready. Your users will appreciate it, and you will be a lot more effective in your work.

Related posts:

1. Iterative Development is Effective Here at SmartMoney, we have been using iterative development techniques...
2. Web Development: Because We Care As a web developer you make a product (the website...
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.

We use BaseCamp here for managing projects. It is extremely popular, so I am not going to go into a detailed tutorial of its benefits. It has really made keeping track of projects and their status a breeze. We even use the API to run custom reports that fit our needs.

When first proposed, I was resistant to using a new piece of software for fear it would slow us down, and ‘cramp our style’.  I couldn’t have been more wrong.  This software keeps everyone updated and reduces the need to remind individuals of their responsibilities and upcoming due dates.  We use it for all groups on a project, not only the tech team.  You can even invite users and clients outside your company to participate on specific projects.  So far we have received very good response from both internal and outside groups.  I suggest you try BaseCamp or something similar.  BaseCamp is by no means the only software of this type out there.  This space is growing more and more as web development moves towards a more agile and iterative style.

Don’t get me wrong, BaseCamp is not perfect. Sometimes it is too simple, even though this is by design.  It is meant solely to assist and not get in the way of a project.  Some people might prefer software that does a little more, or has more reports and graphs.  I personally find status graphs/charts useless and often ignored, and any additional reporting needed is easily customized by using their API.

Does anyone have a favorite of theirs, or better yet, have you tried BaseCamp and another project collaboration product and would like to share your comparison?  If so, feel free to discuss with us in the comments.

Related posts:

1. Using the Basecamp API to Create Project Reports A few months ago I wrote a post describing the...
2. Keep Teams Lean Developing effectively starts with the team. Of course projects requirements,...
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.

Sometimes its hard to effectively share everything among all members of a group.  We have weekly meetings to review our projects and their status and we use project collaboration software but sometimes we simply get absorbed in our own projects and workload.

A great way to share information among team members is through fixing error logs.  For years, our developers were responsible for monitoring and fixing errors on their projects whenever they show up in the error logs.  A year ago I implemented a new system for fixing errors which keeps developers working on new code, and aware of other projects within the group.

We have a team of 5 web developers.  There is an automated nightly process that gathers our application server error logs and distributes them to the development group.  In the past each developer was tasked to look through the logs for errors pertaining to their code or areas of responsibility, and fix them.  This was boring and inefficient.  At times all 5 developers were sifting through the exact same logs, looking at the exact same errors.

Under the new system, the logs are assigned to one developer for the week.  First, they look for errors new projects deployed in the last week or two.  These errors are assigned to the developer or team responsible for that project using bug tracking software.  We use an open source solution written in ColdFusion by Ray Camden called LightHouse Pro.  It works great for us.

With those obvious errors out of the way the developer now looks for patterns in the error logs.  These patterns could be a reoccurring error across the servers, or one server prone to a specific issue.  They may also notice a pattern happening at a certain time of day.  This is one of the many benefits of having the same set of eyes assigned to the error logs for 5 business days in a row.  These errors are addressed first.  If fixing one piece of code can stop a pattern causing 100s of errors, this is your biggest bang for the buck, and most worth the time and effort.  Finally they look through remaining issues and try to work on something they are not familiar with.   A developer is expected to devote about 1.5 – 2 hours each morning of their assigned week.  On Friday, they issue a summary of errors fixed, assigned, and the remaining open errors.

Sometimes when someone in the group is so close to fixing an error, or has invested time and research to that issue, they keep ownership of that issue.  This is not required, but the system fosters a sense of ownership and pride in fixing a problem.

Before we started this system, our logs were a mess and considered a chore to work on.  When we began, our logs could have 1000+ errors in a 24 hour period, and take a full 2 hours each day.  One year later, our logs average a few hundred errors, and usually take an hour or less to work on.  Some weeks, there are only a handful of issues to fix.

The are many benefits to this system.  Everyone gets familiar with various areas of the site they would not normally have worked on.  Developers get familiar with other pieces of code on the site, and get a better sense of the big picture.  We are able to spot error patterns and also get a chance to work with well written code.  All this allows us to develop more effectively on our own projects.

Related posts:

1. Allow Developers To Make Mistakes Keep an environment where developers, and all employees for that...
2. deployment schedules are not effective Simply put, deploying code on a set schedule is not...
3. Keep Teams Lean Developing effectively starts with the team. Of course projects requirements,...

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