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?
I’ve been working on a new project over the last weeks that involves getting TypeScript and Electron working together. Unfortunately, the amount of information available on how to do this correctly is pathetically none existent.
And then there is the whole setup of TypeScript in Node thing. This was mostly my not knowing my editor well. But while we are documenting how to get a TypeScript/Electron app setup, let’s cover that as well.
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.
Over the last week, I’ve been helping other programmers estimate the task they’ve been assigned and this has caused me to reflect on how I estimate software. What works. What doesn’t. What mistakes I see people make.
There has also been a move to avoid estimates entirely. The argument goes something along the lines of, “we know the least about a project at the beginning of the project, so we can’t really give an accurate estimate.” Which is mostly true. And yet, there are people who need to know “how much is this going to cost?” What do we do for them? How do we balance the two realities?
And then all of this lead me to think of all the ways we sabotage our estimates, or our estimates are sabotaged for us.
You might think that estimating projects only applies to project managers. But the truth is, most places I have worked rely on programmers to give them estimates, and frankly, most of us screw this up.