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.