So, What is “Software Engineering” ??? WOW!!! – Part-2


In the [last post] we left at the complexity point of the software. Today we’ll start our discussion from the same point, that is, why software is so complex or what factors are responsible in introducing the complexity or entropy. Also we’ll discuss, what measures shall we take to reduce the entropy factor. As we now know that software engineering is a discipline of producing software product on Industrial scale that is both marketable and profitable and also “maintainable” and “sustainable”.

I’ll explain this broad and mostly overlooked topic by providing an analogy with other engineering discipline. In Chemical Engineering the first step, for the product in hand, is to make a process flow diagram, that are the logical steps in getting the job done. Then we move on and design each equipment / component according to the “well-known procedures” and come up with a design diagram equipped with all the instrumentation, controls and piping, we call it the blue-print and then we take that  blue-print to manufacturing, a prototype is built first. You can easily find a problem during a prototype run and rectify right away. Next step is the scale-up of the prototype / model  is done according to the “well-known scale up procedures” and then the plant is manufactured and the final step is the delivery and erection of the plant, and one more step, if it is designed and modeled properly, the plant runs smoothly and produces the product as expected. Software Engineering is no different in that respect, we follow the same sort of steps, and if each step is not taken properly and according to the “well-known procedures and patterns”, may introduce complexity of very high degree, as compared to other engineering's.

Complexities may be introduced right in the inception phase of the software development life cycle (SDLC) . In this phase where we practice great deal of brain storming and then come up with a set of requirements. Document as much knowledge as you can in this phase, as your project schedule / time line may slip with insufficient requirements details of the project and worst case scenario is you end up with a failed project.  Or may be these complexities are introduced at some later stage during the construction phase, that is where we are in the design phase of the project and we are not following proper design principles, like design patterns. Incorporating Design patterns in your models provides you the benefits of reusability, reliability,  flexibility or extensibility. In order to get greater reusability, design your software in terms of components or follow a component based approach and for flexibility use a pluggable approach. If you miss these guidelines, then at later stage, if you find something is wrong or not working then either you have to rewrite the whole software or it will lead to the legacy code hurdle, and that's a maintenance nightmare. Dividing the architecture in layers using the (MVC) approach also a proven approach in reducing the complexity. During the implementation / coding phase we should follow proper coding standards and always write code with concurrency in mind. Documenting the code is also an important factor. Write tests / unit test to verify the use-cases. Refactor your code at some stage with a quality code, following the standard refactoring methods. Your proper communication is must between developers, that will provide a mean of knowledge transfer and confidence and growth as a team. The team should be a mix of experience and smart software developers. Try to avoid jealousy, politics and bullying in the team that may effect the project schedule. Complexity is inherent in the software industry as the software is a product of human brains may introduce complexities at all stages of software activities like defining, designing, implementing and testing activities as each and every individual is different and you cannot predict the complexities ahead of time. It is also difficult to control and coordinate a group of human beings. Also humans are not like other resources that you use them and throw them. That's not possible. You need to understand their needs and facilitate them with necessary comfort as well as the trust.

Just in case you are in the state of emergency and you know you may miss the schedule or your project might be in jeopardy, consider these refactoring strategies –

  • Refactor the project planning and project handling strategy.
  • Refactor the software team. Make smaller teams and ask the experienced ones to take charge as leads of the teams.
  • Refactor the software development tools – provide the better ones.
  • Refactor the environment, find out what kind of environment can boost the developers productivity, provide them. Facilitate them.
  • Refactor software testing / QA – Introduce automation tools that can boost software testing.

Good news is, you are not alone who is upset with the complexity of the software industry, there is an inherent tendency of entropy exist in this industry. While i was reading a book I found that research from different groups like the CHAOS Report, that is published every year, shows that in 1994 only about 20% of all projects were considered a success by achieving the project goals within budget and time initially estimated. About another 50% of the projects were considered challenged, which means they were either fully functional but over budget, or delivered fewer features than initially planned. The remaining projects, roughly 30%, were considered a failure, which means they were canceled at some point during the development. Also a similar study shows that in 2004 about 30% of all projects were considered a success, around 20% failed, and the other 50% were considered challenged. We see some improvements based on the above refactoring strategies, however, the number of successful projects still only grew by 10% in 10 years, what do you think isn't it a great news ;)

That's all for now folks. So what's our next plan, where are we heading – you know what, need a little break, more on it later, have a good one :)

If you enjoyed reading this blog, leave your valuable feedback and consider subscribing to the RSS feed. You can also subscribe to it by email. Also, you can follow me on Twitter. Thank you!
Comments are closed