The Retrospector

One of the crucial points in a project is near the end where you have to decide to simply wrap things up enough to deliver. The ability to enhance the product forevermore can creep into your scope so easily if you let it. (Scope Creep) Sometimes it gets to the point where you’ll be on an endless timeline of development where you can’t just finish it and get the product shipped.

What I’d like to talk about in this article are some of the things to watch for to make sure you can get your product delivered to your customer. Such things include avoiding scope creep, properly comparing requirements with personal opinions, and follow-through on making sure your product gets to a deliverable state.

Scope Creep

This is a subject that probably has enough issues that it could be an entire series of posts. What I think you should take away from this for today’s article is simply that allowing the scope to broaden or change too much will prevent you from every being able to clamp down on the “moving target” deliverable. You will spend so much more time trying to factor in new features or implementation approaches for a dynamic scope than ever wrapping up the ones you currently have on the table that you will never get the original requirements in a deliverable state.

(more…)

The last few weeks I’ve come across a number of things that required some sort of estimations, so that everyone involved could get a set of expectations in their minds on what would result with each endeaver. (I’ve also noticed quite a few articles about estimation lately.) Tasks range from honey-do projects around the house, to components on an application in the office, to personal estimates on some little things I’d like to just get done.

Estimation is very simple in most cases, but it can get very complex for some things. I’m going to break down some of the issues that effect one’s ability to accurately estimate projects here and hopefully share some insight on how to find your most likely results when forced to think about quantifying your abilities.

Experience

If I had to sum up the art of project estimation in one word, that word would be experience. There’s simply no replacement for what experience can do for you when you have to think about tackling a problem.

If you were given a task of figuring out how to start a campfire, you would have learned the first time around some of the things that don’t work by trial and error. You may have spent an hour trying to get it started the first time, but this time you know you should give plenty of airways to the bottom of the fire to let it breathe while you put the tinder in the flame to get it going. There’s really no way to know that without having experienced it for yourself the first time around.

Case study

Let’s apply this to a scenario at work. Let’s say your boss comes to you and asks how long it’s going to take to get the florescent green with dancing monitors background CSS generator doo-hickey working. Now you know you really need to get this really cool background generator done this week, and if you could get it done today you could impress people. Not only that, but you quickly realize that it’s just some string parsing that you could do blind-folded because it’s just some little class with a few methods for generating color and monitor outlines.

(more…)

I recently read an article by The Curmudgeon Coder that kinda hit home for me in some respects. I can’t agree with everything said in the article, but the 5 reasons stated on why he’s a “Curmudgeon Coder” sort of made me laugh, so I suppose I can at least relate to a lot of what he said regardless of whether I agree entirely or not.

Here’s the 5 reasons he’s a curmudgeon coder:

1. Unnecessary meetings, i.e. SinkHoles of Evil
2. Coding is becoming simpler
3. XML
4. The coders aren’t in charge anymore
5. Fixing the affect of the defect, not the cause of the defect

The list itself isn’t very explanatory. The comments made to describe each one is where the meat of the article is. I thought I’d go ahead and share my thoughts on each topic anyway.

Meetings

I can relate to being forced to sit in unnecessary meetings quite well. I’ve been exposed to very large corporate environments where I simply couldn’t get around at least 1-2 meetings a day with people I hardly interacted with at all. The key is to only make time for the meetings where it really matters that you have something to add or gain from. If you’re not getting anything out of it, and you’re not really adding any value…don’t go. Easier said than done for some, but I’ve found my days far more productive when I simply stopped going to meetings that didn’t seem to add value to my workload or deadlines in any way.

Coding is becoming simpler

He’s referring to the fact that coding has left the arena of bit-shifting and pointer & memory management being part of programming and is moving more toward a framework-based and more automated environment where more and more people are able to make things work with less effort and training. I’ll certainly agree with this point almost entirely. I think it’s very easy for those that think they’ve got a handle on things to fall apart and make big mistakes if they don’t have the fundamentals down though. There’s something to say for the people that not only understand how to use the frameworks, but also know how the framework works under the covers in case something doesn’t go perfectly right the first time around.
(more…)

Every application out there is going to need some debugging. The question that comes to mind is what is the most effective approach to debugging the application you’re working on? There’s a number of ways to debug applications, and everyone has their own war stories on how they’ve figured out some of the most impossible things after digging in the trenches of code.

What I already know is what works for me. I’d like to know what works for everyone else in the same situations. I’ll explain how I’ve seen debugging in the past, and how I think the different methods should be applied.

Common debugging approaches

Here are some of the popular debugging approaches I’ve used and seen used for the most part in every environment I’ve worked in:

• Enable the debugger in your IDE and follow the application’s progress within the code – this particular approach allows you to see the actual flow of the application while it’s being run. You can take a look at the values of all your variables every step through the way and you can fast forward to any point in the code you want to see.
• Insert print statements into the code – this approach allows you to see what code the application is running through by watching the print output. You can see the flow, and print the values of variables onto the screen as they’re being used.
• Modify code and monitor data sources – this one’s a bit more time consuming so I won’t be highlighting it much in this post. Sometimes you simply need to see what your changes did by running the application and watching for changes in the database or in the files you’re working with.

(more…)