When a building contractor first comes to the location of new construction, he doesn't bring the cinder blocks, studs, girders, or even concrete. He brings surveyors and bulldozers. He does "site prep." The way you get a site ready for new construction has a tremendous impact on how smoothly and successfully it runs.
What will happen when he clears the ledge under the planned north wing? More ledge, or maybe very soft earth or even some kind of cave?
How will the spring uncovered by grading the site affect matters?
Didn't anyone know there was a 90-year-old storm sewer zigzagging along long-defunct property lines?
The building envisioned by the architect has a specific shape, size, role, and weight. The architect makes some general assessments of the site, but the reality of the site can seriously disrupt the plans. It's the work of site prep to make sure that the basic attributes of the site will support the plans of the architect in the way the architect needs them to.
Until this is ready, forget the bricks and mortar. Launch in on construction and you'll regret it deeply.
Similarly, software development projects often cause themselves a lot of trouble by starting with software development. It's easy to crank up your favorite IDE, app server and database and start hacking away at a cool-looking prototype. No problem, just package the code up and we'll have a great success!
Er - NO.
Build your build system FIRST. Set up continuous integration and version control FIRST.
Every piece of code you hack together without these tools is rising on the wrong foundation. No, you don't know that it is the same version of Java, of C#, of Websphere, of Oracle.
No, you don't know your own tech stack until you have a build system.
Look, one key difference between building construction and software construction is that building contractors still do simple one-story jobs. We don't. I don't know if there are any trivial software projects left. The complexity we are attempting is way beyond what we did ten and twenty years ago. We've fought to simplify UIs but our success at simplifying UIs should not blind us to the underlying complexity of what those UIs are built on.
Start with the build system, the version control, and continuous integration. These are the site on which you will build. If you start with Java 6, then want to get Java 7 plugged in, these will tell you if it's a success or a nightmare. Your company purchased yet another app server company and now it's your albatross. The new CIO won't tolerate anything written for .Net and CLR. Build-versioning-integration will tell you how bad the damage is and will help you know when you have recovered.
It's hard to phrase this strongly enough. You don't know your project's strengths, weaknesses, liabilities or even your own tech stack until you have captured them with build-versioning-integration. Until then, you're making assumptions. They may be plausible, they may all be correct, but you don't even know what they are. You don't know what risks you're exposed to. Continuous integration may make you grumpy at first, but it will save your project and may save it a lot earlier than you ever thought necessary.