Often times we’re overwhelmed by a number of critical defects that need to be fixed “ASAP”. If you’re using an issue tracker, you have the ability to prioritize issues but what happens if all your issues are the highest priority (blockers)?

A trick that I utilize in my work-flow is to figure out what dependencies each issue has. I ask myself the following questions for each defect assigned to me.

1) Is another teammate dependent on my fixes in order for him to get his job done?
2) Is this issue really stopping the launch? Is there a quick solution that the client is willing to go with in order to successfully launch?
3) Do I need third party support on this issue?
4) Who do I need to talk to get the necessary information to fix this issue?

From the questions above, you can really start to figure out which software defects you should be fixing first. Here’s my opinion on what the queue should be:

1. Teammates come first

The issues you should resolve first are the ones that other teammates are dependent on in order for them to get their job done. A perfect example is if you’re providing core functionality in a library and other developers are building components on top of your code. There will be a point where your teammates won’t be able to progress as they can only do so much with limited testing.

2. Find out what information you need to fix the issue

If you find yourself scratching your head over what the client wants out of an issue; you should fetch that information ASAP. You should never have to assume functionality–always figure out what the clients’ intentions are. This approach leads to less bugs sprouting from what you thought was a fix but really wasn’t.

3. Third-party support has a time-limit

If you’ve ever had to call a support line to get help on third-party integration (cough, Liferay, cough, Omniture), you’ll know that their work hours are the usual 9-5. Incidentally, this means that your time-frame to resolve integration issues is very tight. Generally, whenever you have to get support from a third-party your whole team (even the client you’re working for) should assume that it can be painfully slow or inadequate. I’m not saying Omniture is bad–From my own experience, I think they have the best support: very helpful, very responsive.

4. Is it really a defect or is it a change request?

This is a big question most of the time and requires you to have some back-bone. In most cases of software development, clients will always try to ask you for extra functionality or extra features without having to pay for them. A really easy way to spot this is if they categorize the change request as a “software defect”. A prime example would auto-completion on form fields when the requirements don’t specify that fields have auto-completion–a client response would be, “well all fields should have auto-completion because X, Y, Z, A, B, C sites have it.” It’s very easy to say that but in reality it would require a significant amount of effort to implement that site-wide. Firstly, each field would need to have a data source (auto-completion suggestions), secondly testing all the fields in all browsers. Sometimes, it’s just not worth it and you have to do your best to convince the client that it would eat away at the budget (development time and QA time) for such an “enhancement”.

Furthermore…

What are your thoughts on how to prioritize software defects? Project Unnamed horror stories with how defects are prioritized? Post in the comments below.

Throughout my experience, I’ve always been the type of developer to spend 60+ hour weeks grinding out bug fixes when its crunch time. What does this really mean? It means working all days of the week and making that final push towards a flawless demo to the client.

Recently I’ve been thinking about what really triggers my productivity and how one might motivate others into working harder whether they are your peers or if you’re managing them directly.

Here’s a list that I’ve come with.

• Work hard yourself; make sure your peers know it! This will most likely encourage them to inherit your dedication and work ethic!
• Encourage pair programming! Believe it–it really works! This makes programmers think at different levels and approach problems at different angles.
• Developers constantly hunger knowledge whether its learning a new language or figuring out how to increase performance of X components–that said, always present them with challenges!
• Ensure that they know they are valuable to the project. I can’t stress this enough; if you’re under-utilizing a senior developer by giving him junior level problems to solve then you’ll quickly drain his motivation to work hard.
• Theorycraft! Theorycrafting allows your developers to think of new innovative ways to solve new and old complex problems. Book a meeting room with a whiteboard and think about what problems are at hand when developing new projects and figure out ways to make your lives easier. An example is a reuseable components respository! How many websites have modal dialogs? Can your developers create a reuseable component that would be easily portable to any project they’re thrown on?

This may be a short list; but I’d like to hear your thoughts on how you really encourage your peer developers or the developers you manage yourself to work harder. The “gets things done” attitude is in every strong developer; it’s just a matter of trying to unleash that power.

Cheers,
Jaime

PS: I’ve been planning out my gaming blog for quite some time now but it’s just been pretty hectic at work lately that I’ve been pushing it out more.

Divide and Conquer

I’ve always thought that this blog would be my random thoughts about software development, world of warcraft, and lifestyle; however, after playing around with Google AdSense–it’s actually difficult to achieve targeted ads if I’m talking about several broad topics.

Software development and life experiences related to my career

From now on, jaime.bueza.com will only contain software development related topics and any life experiences that relate to it. This could include: theorycrafting on productivity and efficiency, reviews of different debugging tools, newest web development trends, as well as, general tips on how to improve your site’s performance.

Laid-back versus uptight environments

For the longest time I’ve been working for companies with a casual dress code and laid-back environment. I’ve even seen people wear shorts and t-shirt when there’s a summer heatwave in Vancouver. I define ‘casual’ as allowing employees to wear whatever is comfortable but doesn’t distract anyone from doing their work. Shorts? Absolutely. T-shirt? Absolutely. Nerf guns? Absolutely!

Recently, I’ve had the pleasure of working on-site for a client. When I walked into the building I could smell people wearing suits, ties, polished shoes, and cuff-links. While I’m not particularly used to being in such an uptight environment, I could tell this is a place you definitely can’t shoot your nerf guns.

Office Layouts

One of the first things I noticed is the desk layouts. Each section had 4 desks (1 per corner of the square) and was fortified with a high wall standing at 5-6 feet separating each section. This leads me to think that their teams are always broken down into groups of 4. If a project were to have 12 members, they’d take up 3 sections. To me, this seems rather inefficient. When I look at how much free space there is in the middle, you could probably fit 2-3 more developers and perhaps a 12 foot whiteboard to discuss implementation strategies. At some companies, they have a “V” shape, where you have a 12 foot whiteboard at the back, and then on each side of the “V”, you have developers lined with their desks (see picture below).

You can ask the project manager anything and get a quick response assuming he’s your “V” section. “Is issue #293 of project X a change request or a bug?” — “It’s a change request”. With that kind of communication, I can quickly go on to fixing higher priority defects while the project manager negotiates more money for that change request. Also, I believe a “V” formation is particularly cool because of the Mighty Ducks.

High fives and team work

I’m not going to lie when I say I’m a big fan of giving another developer a high five if he solved a problem that no one else couldn’t. In an uptight environment, how do you congratulate a developer for simplifying a complex algorithm that sorts millions of records per second? A cold hand-shake, “Good job Johnny”.

What do you prefer?

Since most of my work experience comes from laid-back environments, tell me your story on whether you prefer a heavy corporate environment or a very casual environment. Even if you’re not a software developer, do you find yourself wanting to be in a more laid-back environment? or do you want to be in an uptight corporate environment?

YSlow is an awesome tool. One thing I would recommend as a feature request would be to have a more verbose reporting component. Incidentally, there is a tool that was released not too long ago by a developer on the Exceptional Performance mailing list. It is called PageTest. Furthermore, PageTest uses the YSlow criteria for Exceptional Performance. In addition, PageTest allows you to export the report into an Excel spreadsheet.

The only real drawback to using PageTest is its speed (contradiction? I think so, heh). It is a definite work in progress, but it has the baseline functionality that you need as a web developer to deconstruct your web application’s performance levels. There is always room for improvement, such as, sexifying the UI. An awesome feature would be to have the ability to save a performance testing report, like day X, and then 10 days later after re-factoring your code, you can run a performance test again and then do a comparison between the two reports. The delta would show exactly how much your application benefited, whether it be size (KBs), or load times (ms).

On the whole, web developers should be pushing the limits of their applications in terms of performance. The average user will not use a dog-slow application. Concordantly, web developers should always be thinking about how to balance out the three elements that make a rich internet application–Performance, functionality, and user experience. With PageTest, a web developer will have a much easier time in making decisions to balance out performance, functionality, and user experience because PageTest clearly points out the application’s performance pitfalls.