When starting a new project there are a number of factors to consider. There are a multitude of choices available, your choice will most likely be based on prior experience, industry prejudice and influence from friends colleagues and popularity, whats cool at the moment. I will focus on web development here but the general rules apply to any development from systems to embedded systems development. The only thing that changes are the different products available in that particular field.
- Web Server
- SQL Server
- My SQL
- The choices here are almost endless and often may require more than one language depending on the needs of the particular functions you are implementing. They will be dependent on your particular background and experience as well as the time available to learn a new language vs schedule pressure for the project. The resource pools you have available for programming. the important thing here is design and consistency.
- CSS 960
- Some CSS styling method or create your own. The CSS styling is one of the most important aspects of the design. Choosing a good one will reduce the amount of confusion and presentation rewriting over the course of the project.
- Team selection is critical at the beginning phase of the project. Choosing the wrong or weak team members in certain areas will cause delays further down the time line and cause rewriting of code to fix poor design and coding practices. Often one person may take on many roles listed below and should be based on actual knowledge not just a desire to work in that area.
- DB architect
- CSS and Presentation
- Business analyst
- Visionary designer
- System architect
- Hardware architec
- Network design
- Here the choice is critical will you be designing from scratch or expanding on a preexisting platform . The benefits of writing from scratch are flexibility but it may cost schedule time to implement base features that every system needs. User management for example.
- Build it
- Buy it
- Combination of both
My decision the areas listed above are based on a combination of my personal experience, resource availability, longevity of the platform and services in consideration.
One company I was with we were constantly evaluating new platforms to migrate the product to based on what we felt the users would want and what the industry was providing. At that time I went to two presentation by Microsoft where Steve Ballmer was the presenter. This was in the mid to ’80s when he would give presentation direct to the derision makers. The first presentation was on Microsoft Windows 386. If you have not heard of it do a search for the Windows 386 video, showing off the multi tasking aspects of Windows. One of the more embarrassing marketing videos in the MS history. Worth watching if you want some comic relief. The main message of the presentation was “Drop everything and move all programs you are working on to Windows 386! It’s the way of the future.” Later that day I went to a presentation on OS2 and the message as “Drop everything and move all programs you are working on to OS2! It’s the way of the future.”
If you worked on either of the platforms, which I did, you got burnt when the products were dropped. Leaving you with having to rewrite or redo your product in a new environment. The lesson here is be careful when listening Software produces who just want to sell product. Of course sometimes you have no choice when the decision is made by someone else.
Another example and is with Microsoft’s user management functions. The change frequently with no migration path to the new methodology. I have been burnt with at least 4 different versions of this upgrade. The lesson here is do not become too dependent on manufactures bell and whistles in software design as they may not be supported tomorrow leaving you stuck and having to rewrite your code at a moments notice. Unless of course you are one of the top 100 companies and can pressure the manufacture in continuing support for products they want to discontinue.
I try to use a bare minimum of features from the software supplies and do more with less. It reduces the need for training and simplifies understanding code. As you add new team members they can come up to speed faster. Of course you get the age old criticism that your code is not complicated enough. But remember it is harder to write simple code that complicated code that is unmanageable.
Another point to consider is that when designing a system, although efficiency is important, I feel flexibility is more important and I am willing to sacrifice some efficiency for being able to turn on a dime as the market dictates. Remember that if it will take you a few months to optimize your code and you can achieve greater efficiency by throwing the latest hardware at it that runs twice as fast, is the cost of coding outweighed by the cost of the new hardware. More on this in future posts as this is a mistake often made by team members with little practical experience. In my experience real coding efficiencies are often in areas that are overlooked and not understood. In modern compilers often will make the code more efficient for you.
Back to starting a new project. Build your team with a core group of people who are all on the same page. Learn some team building techniques and set standards up front. Document as much as you can for ease of future growth. Sometimes your environment will dictate many of the choices for you depending if this is a start up company or a new project in a larger or existing company. When you do not have free range on what to use, remember the best language or environment to use is the one that you are getting paid to use.