There have been a number of things that have occurred over the last week that have prompted this particular post. And for anyone I work with, this is not an indictment of our work place so much as it is an indictment of our industry. PLEASE don’t take this personally.
Some of those reasons will show up in this article. But the question we need to examine today is why is it so hard to write bug free code. And I’m not even talking about perfection. Why is it that we miss the simple stuff? The stuff that once it is found, we think, “how could we have missed that?!”. I’m perfectly aware that all code has bugs some just haven’t been found yet. I’m also aware that no matter how hard I try, the stupid bugs always make their way past my desk.
Have you ever noticed how, when QA reports a “defect” developers tend to bristle? I first noticed this in myself a few years ago. Now that I’m functioning as a Scrum coach, I’m noticing it in others. Is there a way to have some kind of quality checking in our code that doesn’t make the whole process feel so adversarial? I think so.
I believe there are some adjustments that need to be made organizationally and personally that will bring these two groups together.
But first, why does this problem exist in the first place?
We’ve all been there. Either at the micro level or at the macro level. Business wants to know, “How much is this going to cost me?” And as software developers, we all know the answer is, “more than you were expecting.” We also know that whatever number we give will probably be wrong for a number of reasons. Chief among them is that no one really knows what they want until they see it.
And yet, there has to be some way of providing business what they need and still allowing for unknowns.
So what follows are a few tips on estimating that help you estimate software projects like a pro.
We’ll get to Reasons Projects Succeed soon, but I need to do some setup work first.
I’ve been thinking about starting an Open Source project for a while. The only issue was; I didn’t have an idea for a project that didn’t already exist. Now I do. So, I’ve begun the process.
The issue with starting a project like this is that I would much rather just start coding. In fact, I would much rather not even make this Open Source. But making it Open Source has forced me to face project management issues head on.
I’ve been listening to enough podcast recently to know that putting something up on GitHub isn’t going to make a project Open Source any more than it will make it successful. Therefor, I’ve decided to start the project as though it had a team of people already working on it. It is a team of one for now. But, one thing I’ve learned in life is that having the structure in place to handle a larger team now will not just benefit me in the future, but it will actually help my small little team of me today.
I’ve started looking at other successful Open Source projects to see what they are doing and to determine what components of what they are doing I want to include in my project. As I’ve gone through this exercise, the thought occurred to me, “If the organizations I’ve worked for implemented half of what these projects implement, the projects would have been run so much more efficiently and the projects that were in trouble may have avoided the trouble.”
I’ve been frustrated lately by the flippant use of the words “Scrum” and “Agile” in our industry. They’ve officially made it to the point of “buzzwords that mean nothing” that get slapped onto job requirements like the typical requirements we’ve all seen.