Software Development Should evolve and not desolve

I have written several titles , i have made a big leap in software development strategies. I have utilized domain engineering culture towards developing software. I am against reactive software development. I talked about AZURE , about Google ready to GO , I took you down to the Spider Web Land while telling how we can be Green too. These are very good articles that reflects the happenings in todays agility driven software world. For this flow to continue, todays topic is how we grow our development process with emerging technologies.

All problems and solutions in software land revolves around how we allow our software development process to evolve. How do we grow our process of development? what can we do to ensure our processes are check listed.

Why should software development evolve?
Enterprises needs solutions that fits in properly into their businesses. They require an extensible software packages that makes for quicker responsiveness in changes. They want to say hey "Lets GO" and we are all moving. But wait a minute, we are all moving ? should we all be moving? As part of movements, we shouldn't move too fast nor too slow, we should allow development to grow from an infant into a more mature development process. "Lets GO" though sound more like carry along, but in most contexts "Lets Go" is used by people who does not know how the software will be build (Imagine a plumber fixing your telephone), so i take the word "Lets Go" as being too reactive.

Software development should be allowed to evolve because its a culture driven activities that we must all conform to, there is no island of knowledge, developers should share knowledge. Strategies/standards/patterns are not paper works, sweet tongues, and big grammars. They are meant to be observed and not to be written down or praised. They are critical to business success and they should evolve as the software evolves.

To complement and supplement evolution of software development, developers should be allowed to use their creativity, software process should have a process too, that means the development strategies should always have its own parent strategies to checklist.

Can we be smart with SMART ?

The SEI (Software Engineering Institute) , developed a migration technique called SMART (Service Migration and Reuse Technique), this enable teams of professionals to actualize reuse SOA (Service Oriented Architecture) pattern properly and deliver what a client wants rather than polluting the entire solution with noise.

Migrating legacy systems are becoming problematic because, if proper planning is not observed, we might end up migrating problems we are trying to avoid.

The SMART initiative allows professionals to engage with customers/end users and document their needs, according to their needs, SMART can be strength ed to cater for it. It allows organizations to identify problem areas before software is reused. There are now several versions of SMART which addresses different problem areas. The following have been developed after the initial SMART Methodology :

1. SMART-MP (migration pilot)
2. SMART-SMF (service migration feasibility)
3. SMART-ENV (environment),
4. SMART-ESP (enterprise service portfolio)
   
5. SMART-SYS (system)

All of these are designed and tailored to needs of the customers. This is how flexible we should allow development strategies to evolve.

Reactive Software Developement ( A Lazy Man Engineering ).

What is Reactive Engineering?

Reactive engineering is a principle that most software organizations tend to follow when they fix and sell. Reactive is reacting to problems that could have been resolved if a proactive means is followed using the following : development trends, processes improvements (SPI) , common sense and having smart people take the lead. Reactive can make organizations believe they are closer to the deadline dates, while it makes them believe so, it become tragic when such reactively built software fails, and cost your company millions , or that reactive solutions is not precise enough and cost lives.

Reactive is not only a problem of software engineering, but a problem for the world, we are not fully prepared for worst cases. This article will only point at reactiveness towards software engineering.

When ever a problem occurs during the development or testing of a solution, reactive tends to fix the problem alone, this is more error prone, because what you think you just fixed may introduce another bug latter on.

For software developers, Continuous Integration can make your unit testing strategies proactive, when you make a simple changes, you will need to run all unit tests to see what breaks and what does not.

Development front has improved over the years. We have experienced the leap from assembly languages, procedural, object and object oriented languages. In this modern day of software engineering where domain principles are adopted to further solve development strategies pertaining to its domain area, software is adopted as part of a necessity for todays businesses to survive and for tomorrows businesses to emerge. This means, many businesses large and small all relies on software for their businesses to run smoothly. But what are we software developers/engineers/architects doing to ensure softwares are built in a proactive manner using agile domain engineering principles as opposed to reactive software development.

Scenario One

Ping Pong (Canonical Naming) softwares are aeronautical software development agency based in Asia, Ping Pong develops software that enable an aircraft control systems. Ping Pong in the early years does not have a clearly defined engineering principles that guide the production of its software (This is counter dangerous because Ping Pong are releasing softwares that does not follow regulations and principles) . This software company is endangering the lives of its users and passengers. Ping Pong, in the other hand are very reactive to software changes and bug resolution.

Although Ping Pong are very reactive, they have not met the standards of software engineering principles because they have refused to follow the ethics and professional obligations to the general public.

In real life there is no such company as Ping Pong, this is just an illustration and an example to show how we may be risking life, billions of monies because we bought a software that hasn't followed due diligence. We do not want reactive software engineering but domain engineering, which will keep you proactive and will make your software resilient to future changes.

Scenario Two

Know All software systems is based somewhere in Europe, know All softwares cannot see beyond itself, it does not recognize the fact that software development has evolves, and there are patterns that enable developers to do it right as opposed to do it any how.

Since Know All seems to know it all alone, they do not realize that tools have emerged and processes have changed and the world is moving forward and not backwards. This organization is the father of all reactive technologist, because they hire people that are good in fire fighting, and people who will hide most software problems under a simple fix called hacking (Again Hackers brothers i do not intend to cross the line). Software development is not an industry of patching, there should be no heroic patching, all stakeholders should follow the same patterns of domain engineering so that people speak the same domain vocabularies.


I will always follow a proactive development practice, it saves time and money and it help prevents the image of the software organizations.