No doubt there are advantages to staying the course and continuing to look at the world the way everyone else does. It’s predictable, and most businesses LOVE predictability. Makes sense, right? Now, I am not a classically-trained developer (I’m not a classically-trained anything, for that matter) and most of what I’ve learned about technology has been from a combination of just jumping in and trying things, sheer effort and relying on my sense of creativity. I get that from my mother. I’ve mentioned it before, but I place a much higher value on creativity in my development team than strictly ones and zeros. Too many times I’ve seen projects take much longer than they needed to, simply because the dev team was stuck trying to solve a problem from within their comfort zone, or worse: Telling the client “It’s not possible” or “We need more money.”
It’s often the classic conundrum of Tried and True vs. Blazing Your Own Trail. If you have a high degree of confidence in what you do, you’ll figure it out. Most of the time it’s not your clients’ fault that the project was more complicated than you thought it would be. I start sketching out the solution to the problem in the first meeting so I can get the client talking about the odd corner cases that are inevitably going to surface when development starts. Most dev managers harp on the fact that you need to write detailed requirements before you write code, which is complete and utter bullshit. It’s also a cop-out that does NOT benefit the client. They are hiring YOU to be the expert. YOU figure out how to solve the problem. It would be like a building contractor asking the client about building codes and wiring diagrams. Tell them how much and when you think it will be done and start working on the fun parts.
Am I crazy?