Each year thousands of newly graduated students from fields of Software Engineering or IT related fields seek for jobs. A great number either fascinated by the wealth and power of previous renowned companies or looking for the answer “How did they create such software”, follow those company's path and try to reinvent the wheel without presenting anything new; Well most of which fails.
As a motto a software engineer should burn this phrase into his or her brain, “Don’t reinvent the Wheel”. You never want to build something without at least a partial novelty. One important reason is that you have powerful companies ahead of you to compete with and without at least some parts new your chance to succeed is very low since your competitors have already the product you just decide to produce and they are going to add more features in future. Thus at the time you enter the market they have something newer, better and robuster. Those companies also already have their clients and popularity and the market does not give credit to start-up companies for the same product. Moreover since they have all the resources – knowledge and experience specially—they need, the cost of their ownership is much less than you and they probably present a cheaper product.
Marketing reasons play an important role but it is not the one and only reason why you shouldn't reinvent the wheel especially when you are in the development phase! As a rule of thumb you always start your development by searching for a library or package to provide the functionality you want. This dramatically reduces from your time of development and testing. Sometimes packages meet some of your needs and that’s OK because you can still invest your time just to expand those packages and this is exactly in accord with the essence of open source development in case you use and expand an open source library. After all debugging and troubleshooting is more convenient in this way since you have some sources to rely on their assistance.
Do not develop something already existing unless you just want to gain experience. Your development is valuable for market – either ordinary users or other developer – only when there is some novelty. Without novelty your cost of development is extraordinary high and charged with a market not wanting your product your invention just leaves you cost.
Standards either in form of an organization policy or a public method and library can save an individual or a company. A document format policy for prototype documentation of an organization e.g. storyboards or a common well known grid library e.g. Telerik are all examples of standards. Standards in developers’ eyes have no usages rather than slowing them down and preventing them from plummeting in code. Well this is completely a myth since standards are bringing organizations!
At whatever stage of application life cycle you are you should establish standards before starting anything else. By having standard at place every one from the architect to the end user knows what approach to conform. For instance without a standard for data display a large application UI design confuses the end user and developer at the same time. The developer probably spends a lot of time searching to find a method for rendering and the end user should invest a lot of time learning each application form separately because interfaces are not consistent. It is not the end of story since every single developer does the search and each investigation leads to one implementation. Therefore to get your developer mind together and also to share the knowledge among team members one needs the standard.
When standard is missing troubleshooting is a burdensome job. No one is interested to debug a problem without knowing where to start! Standards by their nature assure you that there are problems everywhere or nowhere at all either you are using a global and renowned vendor standard or you have developed your autonomous company standards. Thus if one is facing a problem that is unique one can skip those modules or components that are developed according to standards and investigate other parts using a local approach. Moreover if you find a way to resolve one case’s error you can expect same solution to apply to next incoming disasters. Furthermore finding solution for non-standard approaches are quiet difficult even if you know what causing the problem because you can acquire nobody’s help since no one else before you went down that road.
Standards organize a company or individual’s development process if they are established before other actions are taken. Although standards if proven to be wrong can cause a great damage the best way to keep the knowledge and accelerate development process is establishing standards. Flow of knowledge and experience between team members are simpler and faster by standards and this leads to the faster development and better quality of final product.
Engineering is a general concept and a software engineer should adopt this general concept and expand it to reflect best of one as an engineer. Engineering principals can be explored in two distinct categories. First Engineers should be committed to some moral codes; Codes such as being honest or responsible. Second producing the best-quality product should be the goal of each engineer. Consequently to develop the best product a software engineer should strive to develop a maintainable product. Despite maintainability using the optimum solution and the most recent technology is a most.
The nature of what an engineer do is different from other professions and this difference is the reason for engineers to follow some moral codes. A dealer does not have to have a productive attitude because they just try to sell what engineers produce. Simply put they do not have the responsibility of supporting what have been produced. Therefore no matter what quality the product has they just advertise things that may not be totally real. In addition to dealers which can be seen as the endpoints clients are dealing with, the mindset of engineers are different than scientists (as the first people to start innovations) too. It is true that engineers base their works on top of what scientists do but they do matter regarding cost and quality.
Maintainability can dramatically reduce from later costs of development. Maintainability in software engineering is more tangible because software engineers are different from other groups of engineers. This difference is caused from the fact that there are rare occasions that software engineers are not forced to change what they have produced either because of a mistake in requirement analysis or the client new requirement. As a matter of fact software development has an incessant life cycle. Thus without qualities such as maintainability and re-usability the cost of change is so high simply because the time to make the changes is high.
Engineers should know that feasibility most of the time is not the real issue but implementation of the idea in the time frame constraint and the cost are. To decrease the time of development engineers should choose the most appropriate tools and methods. Most of the time new technologies reduce the time of development therefore to be familiar with new technologies a software engineer should always be updated. Moreover they should employ creative solutions in order to contract time of development. The first solution that strikes the mind is not always the best one and brain storming is needed to find the most optimum solution.
To sum up software engineers follow the same path as other engineers do except that software life cycle is never ending and this cause additional considerations in development. In addition to moral codes software engineers should obtain features such as maintainability and usage of recent technology that can affect the quality which is the foundation of any engineering justification. These criteria help software engineer to develop the best product having the lowest cost which is utopia for both the engineer and the client.