If you read my last post about the long awaited Rosairo , you will understand fully well, the richness of what the future hold in stock for all of us.
Come This April 12, the .NET community will experience a change in software development while leveraging the .NET 4.0 and new enhanced WWF (Windows Workflow Foundation), Advanced and Rapid WCF (Windows Communication Foundation) . This will mark the true begining of us all in the .NET Land.
In my experience with developers, catching up with technologies is very difficult because of the rate at which technologies changes in the .NET front. This might leave some developers obsolette because some have'nt tried their hands on LINQ , Extension method , anonymous type e.t.c This isnt nobodys fault but some justifications while this new futures are there. I recently interviewed a C# developer remotely about his abilities on the .NET framework, he said ! ".NET stopped bieign .NET since 3.0/3.5, he went on saying that .NET 2.0 is the best of all."
Everybody is entitled to his/her own opinion, if a new feature appeals to you, use it, if else then throw it away. Visual studio .NET IDE now allows you to switch frameworks, so you can go back to previous framework version.
Never the less, new changes are driven by Customer requirements , bug fixes , industry defined and endorsed patterns. So not to worry, because They are here already!
I cant wait no more , click here to try it out
Tuesday, March 16, 2010
Friday, January 29, 2010
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 :
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 :
- SMART-MP (migration pilot)
- SMART-SMF (service migration feasibility)
- SMART-ENV (environment),
- SMART-ESP (enterprise service portfolio)
- SMART-SYS (system)
Friday, January 15, 2010
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.
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.
Tuesday, December 15, 2009
Consume RestFul Service as Object using WCF.

As an enterprise software engineer, i deal with disparate systems. I deal with several impedance mismatches between these systems, i built several integration components to glue these systems together. Many of these systems have its domain semantics (They speak different languages ), my daily work life activities is to build abstractions over semantics of different and disparate systems. I am one of those software engineers that believe in domain engineering paradigm , separation of concerns (A dog is a dog not a dogcat) , inversion of control e.t.c I enjoy spending time on a solution to see how it could be done better.My daily work is so challenging that bringing systems together from multiple domain is my strength and i have used aspect orientation to my advantage.
Recently, i entered a problem, we have an application that exposes objects as pure xml , the application supports soap 11 . The soap envelope does not have an action (Simply put in in WCF terms, it does not have an OperationContract , so when you consume this service, there is no web service operations to call on it ), This application only accepts pure XML as request and returns xml as response.
This is chaos, i know some hackers would say there is no biggy here, just construct an string as xml, send it over to the REST service and get the response as string and use linq or manually tranverse the string and construct an object from it. Wao! this indeeed is a hacky packy solution (Forgive me hackers brothers, i do not intend to cross the line). We are now in the world of objects, things have changed, newer platforms have emerged.
The diagram above speaks more of my scenarios, XML input and XML output using the good old REST Service approach. How am i suppose to translate these XML returned as string into object , how does WCF Channel Factories come into play with these. Keep focus, i will explain how i did the magic ...
First : Call the service from web browser , or get the schema of all the objects returned by the service. I chose the first option for my scenario as there was no schema, so what did i do, i called the web service from a browser , saved it as anything.xml , then i opened visual studio command prompt , ran the XSD.EXE command using the following parameters :
xsd anything.xml /outputdir:mydir
The command above, generates the schema from the xml which i saved from the browser called anything.xml. Now that i have my .xsd file handy, i can generate a .net class using the same xsd.exe command but with different parameters. Thats the price to pay.
Now i have anything.xsd in my output directory , i would like to generate .net classes using the follwoing command :
xsd /c anything.xsd
This generates C# classes for me. Now i am equiped with the object representations of the XML that the REST service sends to my consuming applications.
Second : How do i send request and recieve response from the REST Service ?
To do this, you would need to understand how to use low level WCF communication classes to send soap messages back and fort. First i want to have a mechanism that will enable me to serialize and de-serialize my soap messages Request messages : The following is an example request object :
Sample XML Request
<hellorest>
<message>Get Hello world </message>
</hellorest>
<message>Get Hello world </message>
</hellorest>
Now that we have carefully reviewed the generated c-sharp class we can proceed to creating the request object. Since we have the request xml above, we will have to hand code this as a c-sharp class. Using the good old System.Xml.Serialization namespace, we would decorate our request class with xml attributes for pure serialization. Here is our sample request object and a Serialization method :
[XmlRoot( "hellorest" )]
public class RESTWebRequest
{
[XmlElement( "Message" )]
public string Message
{
get;
set;
}
public RESTWebRequest( )
{
}
public XmlElement SoapSerialization( )
{
XmlSerializer serializer = new XmlSerializer( typeof( RESTWebRequest ) );
StringWriter writer = new StringWriter( );
serializer.Serialize( writer , this );
XmlDocument xmlDocument = new XmlDocument( );
xmlDocument.Load( new StringReader( writer.ToString( ) ) );
return xmlDocument.DocumentElement;
}
}
Having done that, we are ready to use the communication classes within WCF from the lower level to send our request object and receive our response as object too. To do this, we need to understand the following classes with the System.ServiceModel namespace :
1. Message : Wraps the request/response in a soap envelope.
2. BasicHttpBinding : Communication ensured via HTTP .
3. IRequestChannel
4. IChannelFactory
The listed interfaces and classes would be used to send and recieve , serialize and de-serialize soap messages. Now the long awaited class, the RestAgent which will be used to send and recieve messages is defined below :
internal class RESTAgent : IDisposable
{
IChannelFactory
internal string EndPoint { get; set; }
internal RESTAgent( string EndPoint )
{
BasicHttpBinding basicHttpBinding = new BasicHttpBinding( );
basicHttpBinding.MaxReceivedMessageSize = 1000;
this.EndPoint = EndPoint;
channel = basicHttpBinding.BuildChannelFactory
(
new BindingParameterCollection( )
);
channel.Open( );
}
internal GeneratedFromXSD GetResponset( RESTWebRequest webRequest )
{
Message requestMessage = CreateIncomingMessage( webRequest );
IRequestChannel requestChannel = GetRequestChannel( );
requestChannel.Open( );
//Hey. time out here is ugly.
Message responseMessage = requestChannel.Request( requestMessage , new TimeSpan( 1 , 20 , 00 ) ); //1 hour
requestMessage.Close( );
GeneratedFromXSD anything = DeserializeXMLStream( GetMessageContent( responseMessage ) );
responseMessage.Close( );
return anything;
}
private GeneratedFromXSD DeserializeXMLStream( string xmlStream )
{
XmlSerializer serializer = new XmlSerializer( typeof( GeneratedFromXSD ) );
return ( GeneratedFromXSD ) serializer.Deserialize( new StringReader( xmlStream ) );
}
private string GetMessageContent( Message message )
{
XmlDictionaryReader xmlReader = message.GetReaderAtBodyContents( );
return xmlReader.ReadInnerXml( );
}
private System.ServiceModel.Channels.Message CreateIncomingMessage( RESTWebRequest request )
{
XmlNodeReader reader = new XmlNodeReader( request.SoapSerialization( ) );
return Message.CreateMessage( MessageVersion.Soap11 , "" , reader ); //Give us the real thing. Wrap up with soap envelope without a specific action = ""
}
private IRequestChannel GetRequestChannel()
{
return channel.CreateChannel( new EndpointAddress( EndPoint ) );
}
public void Dispose( )
{
channel.Close( );
}
}
You can use the RESTAgent class to send and recieve soap message from our Restful service by using the follwoing :
RESTWebRequest request = new RESTWebRequest();
request.Message = "Hello world";
RESTAgent agent = new RESTAgent( "http://localhost/restapi" ); //Parameter is the endpoint address
GeneratedFromXSD anything = agent. GetResponset( request );
Tuesday, November 17, 2009
The Story of the Spider Web Software (Part 1)
This article is a long story line of software projects, practices and cultures that contributed to the failure aspect of software development. The story of the Spider Web Software is all about how you and I have turned software engineering institution into a chaotic industry. This is not Blame, nor one of those cries, because you and I needs to accept the fact that we are not following due-diligence.
Not anymore do people , engineers , end-users and business owners whose daily interactions with software have diminished could say a good thing about that new solution. People are loosing their confidence, end-users are sticking to their manual processes instead of living with crappy solutions that we once persuaded them to use (Dictatorship, you must use it to be compliant with the world => this is a big lie).
Software industry is experiencing a vote of no confidence from all angles of the industry, just because of what ? because we built what we are asked to build => "The Spider Web Software" . If you do not build it their way, you are an enemy of state with all eyes on you, the only way out is to join the Open source community. From a disciplined industry into a free for all industry, Software industry will continue to suffer these pathetic problems mutilating the profession. I am ashamed to call myself a software enthusiast , i cry inside for several failed projects which could have been avoided at the initial stage.
Not every software is a piece of crap, not every pragmatic development is wasted; not every solution meets the users need. But at least, in the systems development front, there have been more successful software stories and many software have experienced growth from its initial version 0.0.0.1 to 0.0.x.2, at least a quantum leap. Get ready for the story, close your eyes, open them, close it again .... wala :
In the land of Spidery
Once upon a time (time - time), in the ancient town of spidery in faraway land, there lived a the very strong people of the land blessed with shelter, shields (anti-virus), clothing's and a massive web which connects and support the foundation of the land. For 1000 years, the people of this land have lived and conquered their challenges, all have worked in a team spirit fashion to the successful of their legacies.
Happy, these people were, until modernization came into the lime light, the stories of how cities were emerging reached the land of Spidery. The king summoned his cabinets, and they decided to follow the trends rather than taking the step at a time, they wanted to dive into modernization straight away.
It was a good idea says one cabinet member, at least in one day we will have trains (Bakerloo , waterloo), sky scrappers, parks and standard environment, that would make life easy. Do not get me wrong, the Spidery kingdom is very rich (Milk and honey flows on the land). The cabinets and the king all agreed, that it was time they change the kingdom in one day. News of the changes had reached the entire world. Even the Spidery Kingdom have a way of celebrating their successes even before the success.
Not anymore do people , engineers , end-users and business owners whose daily interactions with software have diminished could say a good thing about that new solution. People are loosing their confidence, end-users are sticking to their manual processes instead of living with crappy solutions that we once persuaded them to use (Dictatorship, you must use it to be compliant with the world => this is a big lie).
Software industry is experiencing a vote of no confidence from all angles of the industry, just because of what ? because we built what we are asked to build => "The Spider Web Software" . If you do not build it their way, you are an enemy of state with all eyes on you, the only way out is to join the Open source community. From a disciplined industry into a free for all industry, Software industry will continue to suffer these pathetic problems mutilating the profession. I am ashamed to call myself a software enthusiast , i cry inside for several failed projects which could have been avoided at the initial stage.
Not every software is a piece of crap, not every pragmatic development is wasted; not every solution meets the users need. But at least, in the systems development front, there have been more successful software stories and many software have experienced growth from its initial version 0.0.0.1 to 0.0.x.2, at least a quantum leap. Get ready for the story, close your eyes, open them, close it again .... wala :
In the land of Spidery
Once upon a time (time - time), in the ancient town of spidery in faraway land, there lived a the very strong people of the land blessed with shelter, shields (anti-virus), clothing's and a massive web which connects and support the foundation of the land. For 1000 years, the people of this land have lived and conquered their challenges, all have worked in a team spirit fashion to the successful of their legacies.
Happy, these people were, until modernization came into the lime light, the stories of how cities were emerging reached the land of Spidery. The king summoned his cabinets, and they decided to follow the trends rather than taking the step at a time, they wanted to dive into modernization straight away.
It was a good idea says one cabinet member, at least in one day we will have trains (Bakerloo , waterloo), sky scrappers, parks and standard environment, that would make life easy. Do not get me wrong, the Spidery kingdom is very rich (Milk and honey flows on the land). The cabinets and the king all agreed, that it was time they change the kingdom in one day. News of the changes had reached the entire world. Even the Spidery Kingdom have a way of celebrating their successes even before the success.
Now, when the integration starts, many loop holes where discovered, and instead of going back to the drawing board to re-design the architecture of the new modern spidery land, they insist on going on. At a point the people of the kingdom saw the direction where modernization is taking them, they realized that everything that is glued together can easily fall apart if one of it fails, it was too late to change the designs to separation of concerns , the train line , city centers shops , bars , buses , electricity , houses , airports are all linked together with a very tightly coupled manner , that if one fails others would not run. Its was a bad moment for the people of spidery, the preferred to be in their olden and conservative lifestyles rather than leaping into modernization in one day , it was a day that they will never forget.
Wednesday, November 11, 2009
Google is Ready to "GO"
There is a new addition to the Object Object Oriented programming platform , codenamed GO (A new addition and descendant of the C family) by Google. It is said to take advantages of new trends in the software versus hardware community. Go will take advantage of dynamic languages like python, it is said to have an efficient Garbage collection, runtime speed close to C language and full support for multi-core processor from ground up.
Go is blessed with true closures and reflection (Programmers delight to extending the framework). The reasons behind the introduction of GO is that the older languages have failed to include current computing trends like fast programming, expressiveness (Functional), multi-processors, true closures . I personally love the idea of methods/functions returning multiple values. Although i struggle with the return type after the method parameter.
Is Go the future that we all want?
The problems claimed to be solved by Go is already taken care of by mature object oriented programming languages. Go should not be seen as a replacement for C# or Java etc but a language introduced specifically to solve specific computing problems. C# is still in its infants and we have experienced more powerful programming concepts and constructs that Go claims to be a silver bullet for.
Dynamic language integration is already a number one citizen of todays languages, Java has the Rhino (Integrates with JavaScript), and C# 4.0 is coming with the dynamic keyword to solve Com inter op problems and integration with more dynamic language. .NET is a platform that cannot just be thrown away, because it already blends with todays problems and it is constantly being updated to support features required to develop todays application.
What does programmers want?
We want a unified programming platform, we would like to see all object oriented programming languages to have very easy integration and it is not wise to introduce new language to address specific problems. If you are a system integrator and an advance developer, you would realize that bringing platforms together is more fury. We would love to see a bridge across platforms, enough of this chaos.
Will Go Make it?
well, it is still experimental and we are all allowed to contribute to it because its completely free. Go still have a lot of hurdles to pass through like every other new language, it will survive most of this hurdle but if it is focused on the right direction. I personally does not see it as a replacement for any of the more matured and advanced languages.
Share your views. and Go for Go here.
Monday, September 14, 2009
Software Development Can be Green Too. (Part 1)
The new wave in our industry "GREEN IT" , is rapidly becoming the IT buzz of the moment. Almost anything you do in computing nowadays needs to under go the green scrutiny. In other to cut cost and save our ecosystem. Recently i went on a computer gadget parade at Soho (down town London west-end), i noticed a gadget that i loved, asked for the price, the store assistant had to check records to confirm the new price is not different from the one on the sticker. I asked why they could not use an electronic price indicator, he answered : "We want to be green".Most people, organization and professionals read meanings to the definition of "GREEN Computing" just like any other computing phrase and jargon, it can mean differently when used in different context. We need to exercise caution when we form our own theories around the "GREEN Computing" word, because wanting to be green should not mean you would disregard what is efficient over what is not. Because you need to be green does not mean you would not provide your customers, staffs with what will make life easier in the workplace and as a product.
Nowadays, every organizations (large and small) are going into green computing foray to utilize resources and energy. The green aspect is to ensure that, there is adequate resources and that project leads/managers/technical leads/architects/business analysts proactively utilizes what is left of them in a cost effective way. Green must ensure resources are maximized and reused accordingly during project development.
What exactly is "GREEN" Computing or IT
Green IT is a computer word that favors efficient production/use of computer resources without any dangerous impacts on our environment. It also mean cutting cost on what we can reuse (It favors Re usability over Recycle - New ). Most computing resources consume a great deal of energy and the cost run into millions to maintain yearly, if we try to be green we can save a lot on environment and cost.
Is That all. No! "GREEN IT" also means
We change our practices, we obey our ethical responsibilities to the society at large. We need to be green before encouraging it. (For example i am green about my spending habbit).
Cloud Computing will take us to the greener pastures
With the Internet becoming so powerful and broadband s are becoming cheaper everyday. It is now wise to take big advantage of the next revolution of our industry, the cloud. Although i can always argue that we are already in the cloud era, right from the 50s and early 60s when the US military used Internet to boost their military operations, and since then, the skies have become the limit, we have experienced the advancing Internet revolution, and within the same era, here come the cloud.
More development should be targeted at the cloud, their is a green advantage on the usage of software systems over the wire compared to conventional run from local system. This approach will reduce cost of installations, cost per head of users and of course the cost of maintaining a server will be taken of you and it will be the responsibilities of the cloud provider. In short cloud computing will take us to the greener pastures.
Now we need GREEN Software Development
Computer hardware does not exist alone, they are produced to complement and supplement the software written by us. You may start to think, that if hardware is useless without a software, that means the software itself consumes resources from the hardware, and the more resources a software consumes the higher the rate of electricity, network packets that the hardware will be forced to use.
To be greener in development, we should try to write code that can be reused across our application domain. We should try and employ domain driven engineering principles (Most organizations write the same code over again because they could not define their domain).
Software as an assets, if you define your domain well, and everything you need are in place and you have a catalogs of domain artifacts assets, this mean your organization is practicing green development.
Get experienced developers to influence the in-experience one, make awareness about the importance of modularizing your components. Use AOP (Aspect Oriented Programming) like you have never done before.
We need to embrace greener coding styles, which will include more focus on software performance, the exploitation of multi threaded and parallel computing. We need to retrain and ensure that software development standards are used to build software and not just delivering crappy software. If we want to be greener in software development approaches, then we have to imbibe the culture of using standards. This will take us back to the days scarce hardware resources.
Green Coding Standards
1. If you are building large tree structure of objects which requires recursion or the visitor pattern, then you will need to cache your output to by pass the same recursion when you require the same output. A slower system makes use of resources.
2. Use design patterns effortlessly. A pragmatic developer would appreciate that common and recurring problems can be solved using a library of knowledge. It is wise for software houses to document that knowledge.
3. Agile developers believes that TDD (Test Driven Development), when practiced to its fullest represents the full specification of a software. In fact TDD believes that tests are the documentation, I am also a strong believer of this. If you make use of scenario based TDD, you will understand that TDD can cover all aspects of your application. If TDD can represent your documentation, why write another bogus documentation wasting paper resources, and re-writing such documentation when something simple changes in own code.
4. Make use of Code Generators, ORM facilities, this will bring you very close to the market place. They are an existing strategies proven to be successful, and reduces code bloat. A good one is this : Rapid Entity Framework.
5. Use Open source : Open source will make you greener and there is no hidden cost the software is completely free to distribute. Open source projects are delivered on time and patches are made on time.
6. Ensure your program does not have bottlenecks. Ensure your code does not take long to achieve its aspect.
7. Be performance aware, an application that consumes resources alot consumes electricity, and so therefore such applications are not green.
We cannot help it, we only develop what works.
Many developers, especially those who are much more around in IT industry today, are more focused on getting faster to the market and during the process, they end up with a product that misses its deadline, a product that is fragile and breaks down every hour, an un-maintainable code base. I can hear some developers already throwing blames at their managers for not allowing them to follow industry standards before software is delivered. Well some managers do not understand (Make them understand and let them know its importance), some managers do understand but their superiors do not understand. These are the problems that IT is facing today.
If we keep focusing on hardware alone in other to be green, then we are half way in reaching the greener pastures. Software development can be green too.
Subscribe to:
Posts (Atom)
Command architecture and dependency injection
On a recent project, we were mapping commands to user intentions, covering all aspects pertaining to the usage of the application from the p...
-
Application state is one of the most underrated aspect of any software development. Developers want to solve problems quickly enough and ...
-
This is not particularly and fully related to ASP.NET but the main project which I extracted this concept from is an asp.net project, so I h...
-
I received the Chartered IT Professional Status award from The British Computer Society . The award is part of professional achievement th...