Software Design Charactristics

Now a days I am reading a fantastic book Code Complete 2 written by one of the finest and famous writer of Software Engineering books Steve McConnell. This blog will actually now served me as keeping notes and important points from this book so that I can use these points as reference and also to share it with all of you.

Although this books is mostly about software construction but he also described the characteristics of a well designed software. Bellow I am presenting these Characteristics with their key concepts.

Minimal Complexity:

•  Keep your design simpe and easy to understand don't make clever designs because they are hard to understand.

Ease of Maintenance:

• Design the system to be self-explanatory.
  

Minimal Connectedness:

• Means designing so that you hold connections among defferent parts of a program to a minimum. Use the principles of strong cohesion, Loose coupling, and information hiding to design classes with as few interconnections as possible.

Exensibility:

• Extensibility means that you can enhance a system without effecting other parts.

Reusability:

• Design a system in such a way that you will be able to use the work you've already done in other system where there is a similar functionality needed.

High fan-in:

• Referes to having a high number of classes that use a given class.

Low-to-Medium fan-out:

• Means a given class use a low-to-medium number of other classes.

Probability:

• Probability means designing system in such a way that it can easily be moved to another environment.

Leanness:

• means designing the system so that it has no extra parts.
  

Stratification:

• Stratified design means trying to keep the levels of decomposition stratified so that you can view the system at any single level and get a consistent view.

• If yor're writing a modern system that has to use a lot of older, poorly designed code, write a layer of new system that's responsible for interfacing with the bad code. Design the layer so that it hides the poor quality of the old code, presenting a consistent set of services to the newer layers.

Standard techniques:

• Try to use standardized and common approaches or It'll be very much difficult for someone to understand it first time.

Lessons Learned

I can say this for sure that the things you learn from a bad project or near to disaster project is far more valuable then from a good project. I'm facing the same situation.

First let me present the history of the project that will give you a chance to analyze from where this all has started that in the end move towards the disaster (which is not actually the case now).

A firm has given us a proposal to develop a complete reporting website that will present about 17 reports based on a Queue Management System's back-end Database and without any feasibility study we accepted the proposal.

Impact: We've just created a mess for us right here
Lesson Learned: Must Do Feasibility Study

We must do feasibility study before accepting any of the project, we must analyze, the project which we are accepting by asking a question, "Are we capable enough to develop this project?"

The developer who was previously working on this project have made about 4 reports and guess what they were completely generated by a custom tool, He haven't write a single line of code by hand and when we look at the nature of the project they actually require highly customized reports. When he shipped these 4 reports you can guess what would happen yeah! all of them were a crap and sent back to the company by the client.

Impact: Effecting Company's Image
Lesson Learned: Adopt strategy after analyzing the nature of the project for development

Another mistake we've made is that we completely relied on the Client's given Requirements which was a big mistake, Requirements Engineering in itself is a big topic to cover here but sometimes or most of the time client don't even know what he/she is talking about, what he needs, so, you should ask him questions why you need this feature? what benefit it will provide you?


Impact: Following wrong Requirements; Developing wrong Things no matter how perfectly you develop them It'll be useless in the end.
Lesson Learned: Always make specs before starting the project

Now previous software developer have left the job and have given me the opportunity to watch the show 'How a Project can be a disaster', I've received the work which he has done on this project which was completely out of synchronization and was not according to the initial requirements, I've tried to change its shape according to the requirements but failed to do so. Everything has to be done from scratch.


Impact: Wasted a lot of time
Lesson Learned: Time is one of the factor that determine Project's success

I've analyzed one more thing, clients actually have a habit of requesting a change and then rejecting it, It doesn't matter at first but when time is a critical factor in determining a project's success then it does matter, how much you have already worked on the change client has requested? and whether new implementation will take more time time then the previous one? If so it will definitely hurt the delivery date and won't allow you to complete the project within time and within budget. In this scenario management should negotiate with the client about the consequences and effects of this change in overall quality of the product etc.


Impact: Trying to make project unsuccessful
Lesson Learned: Negotiate and Stay within budget

cont...

Future of VB.NET

At PDC 2008 Microsoft has unveiled VB.NET's Next version, watch the cool new features VB has to offer in the next version i.e. 10.0 and also where It's heading... Technology is changing at a mind boggling speed!

http://channel9.msdn.com/pdc2008/TL12/

Things you should Learn

Although this post has nothing to do with Technology or .NET in anyway but It's worth reading http://www.downes.ca/post/38502

Why do we Blog?

Blogging means different to different people, Some may use it for portraying their feelings or sharing their knowledge, Some use it to expand and advertise their businesses while other use it to simply create an impression that they have a blog actually :). But blogging for me is quite a different thing as compared to the other fellows, I Blog because it lets me analyze what I've learned where I am standing, It actually provided me with an opportunity to polish my skills because to write a single post it includes a bit of research but how extensive depends on the Topic itself, this actually provide me with an another opportunity to discover and to learn the new things that come in the way while trying to describe the topic in hand.

Some people often argue they haven't came across a single post on various blogs where visitors have left a single comment, it means no one is bothering to read your post so why to waste time? But they have failed to analyze that the writer himself is learning far more better because this extra effort actually giving him the command over the topic he's writing and let him analyze the mistakes and flaws in it because human brain actually thinks one thing at a time, For example in Software designing phase if the design is in your head and you just start coding later in the development stage you will certainly feel some thing is wrong or the design is not coming up the way it should be on the other hand if you draw that design on a piece of paper you'll be in a better position to decide whether or not to use it, how much potential it has and also gives you the choice to come up with alternative designs and research shows teams who document their designs tends to have better products.

So, I am just following the same principle !