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.
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.”
As popular as Node is, I am still finding that many of the people I work with have no idea what it is or if they do, they only have a partial idea and can’t see how it would apply to the work they do on a daily basis.
The MVVM design pattern has been around for quite a while now. It has a lot of strengths when done correctly. But, I believe the time has come to recognize that MVVM has a lot of shortcomings that point to its demise. Since I primarily develop web applications, I will keep this discussion centered on the use of MVVM in web applications. The use of MVVM for desktop may or may not have these same issues.
I realize that for some of you, the very suggestion of dropping MVVM will invoke a negative emotional response. Some very smart people have quit their job at the suggestion that MVVM and its close cousin two-way data-binding, be abandoned in favor of another way. But just for a few minutes, I would like for you to stop treating programming as a religion and consider the possibility that there may be a better way.