--Originally published at Debugging My Mind
Whenever a new project arises, becoming a potential client, software devloppers jump at the opportunity promising and proposing fantastical and optimistic things, it feels like when you’re told “tips” for job interviews, you want to exaggerate and be as optimistic as possible, nothing bad, only good stuff. Thanks to this, everything becomes “possible” and very attractive time estimates are given really fast, even when estimating the time for a project can be incredibly difficult and probably needs time itself.
I think that’s the main problem, nobody wants to say that something is impossible or that it will take really long, everyone wants to “look good” about their proposals so they get the job, but isn’t failing and delivering late, or even failing the project altogether worse?
Some time ago when I began studying software engineering, I had teachers be very persitent with saying “you’re not programmers, you’re engineers”, we are not being taught to be programmers, anybody can do that, and the way software development is handled a lot of the times is from the programmer perspective. “Sure I can do this”, “Yes this can be done in X time”. Being engineer means being able to plan things, to make estimates and evaluate the given problem, use logical and exact knowledge to backup their decisions.
It’s true than in many other work areas, including engineering benefit from just adding more people to projects to make them finish faster, divide all the work load and ta-da~ it works, but this is definitely not the case with software. Why would it sound better to make smaller teams for projects instead of adding more people, simply because in my own experience it takes more effort to coordinate everyone, to have each of the members be in sync with what’s going on and what must be done. Work can’t be as easily divided and assigned separately unless it’s completely independant from the rest, which is a difficult thing to come by in software. You can try and make modules and functions as less dependant as you can, but they’re still gonna need to integrate with the others and communicate, you can’t have the groups of people working on them completely isolate from each other and expect everything to go well.
I agree with how the “Man-Month” formula is a myth for software development, how we’re currently on the transition of understanding the fact that this engineering area of work isn’t the same as the rest, how the “common rules for work” don’t translate that easily and how a general mindset must be done to correct all of this.
