Designing Software

Designing Software.

What is it really, is it really worth my time to spend some minutes to take this blog forward. Does this help, The Answer is yes. It is worth your time.

The Question is what is Design?

As like an Old school dictionary definition Design is a mapping of the concept or an idea to Implementation. Is it sufficient to put our thoughts to make thing Done? That’s what our managers think its lot more than that less see throughout of this blog what all the things make good Software or Typically what generic thing makes a system well Designed.

1. When Should we Design?

Here we are all Software developers whose ideal goal is to write code by staring at the monitors. But doesn’t happen we are responsible take a refined requirement and move through the existing system relating it to problems on our hand. Later part is to press the trigger isn’t it. 

Yes, we are all most often to be involved in Designing Software in one way or the Other.

Then is there any method to follow?

Yes,

The oldest methodologies of developing software are the Waterfall model.

Designing a whole problem on the single shot and let the programmes to code. We all know that sucks. This method is also known as Big Up Front Design. We have avoided those things more often we later discuss what are all the things that can be done to avoid this kind of mistake you could have things what’s the problem in designing on the single shot and moving to Code. The software is always in effect to change the dependencies on an existing code base ability to evolve may make the system more complex to maintain.

Just In Time Design- this is carried out by most of the programmers when they sit to code like most often what is related variable, what are the methods or Behaviours most of this class included and how is this class is related to other classes do I introduce a Interface and so on this Just in time design is also known as Tactical Design (trying to separate out the necessary  details say variables and methods and relating the grounded details with respect to context or a Domain we are solving it.) 

The other most top trending Method nowadays is Agile.its developing software in small patches. does it really make a Good system through Agile the Answer is no? It depends, we still suck at what we do. And call our self agile. Methodologies have nothing to do with creating a Good design they are just proven pathways get things done more. 

The greatest things what we have to take up with agile is Feedback. A Quick FeedBack agile can be also called as feedback Driven Development.

2. How to Know if the design is good?

Is there any instrument is there to measure the Good Design. No, there are some methodologies to say whether a system is a good design or not.

These are Key Mantras.

1.Easy to Read - Easy to understand a code based on the context with ease and more quickly.

2.Easy to maintain- Software is not written, Software is re-written. Software should affect minimalistic change. The Software which is hard to maintain results in other drastic changes in the system. It takes a lot of time to fix bugs, crossing deadlines, Increases in the cost of production and difficult to extend or scale the project so on and on.

3. Fails lot less- Software which is not full of bugs.

Then how to make a system good Design.

Avoid implementing random Features.

The Software we write is used by some else for the customer or user not for ourselves whenever we are including a feature to our application ask some questions do we need it now And how valuable is this feature from a user point of view or a business point of view. For eg: It is said to only 20 percent of the features are only used by the users or Customer who is using the application.What a shame in developing thing which the customer or a user won’t care of more often isn’t it.

Always have this principle in mind You Don’t Gonna Need It - Now(YAGNI).

Create user stories give value for those stories with a number 1-10.

Which is the feature that is necessary to implement at that point of time this makes your application most minimalistic and concise? Instead of Bloating all the unnecessary code in the application which may result in bugs. 

3.Influence of language and Paradigms on Design.

does the language and Paradigms affects the design. Yes, they do. the way we code in OO languages like C++, Java, Python is way different than coding in languages like Groovy,Ruby or Closure. The feature in one language can make a design to implement in a whole new way. So one should always aware of what the languages provide us to solve a particular problem on hand.

Its lot more different to code the same problem in different Paradigm(OO or Functional Programming Methodologies)

4. Why is it hard to develop a Software?

The hard thing always is to predict the future isn’t it. yes, the code base what we have definitely gonna change it may redefine the requirements or extending the application through introducing new features. Most important thing is we don’t know what the real outcome of the design isn’t it this happens to most of the developer because lack of communication between the People with the domain expert or lots of assumption made in context to the Domain we are solving result in software which does not do what it wanted and most of the project often fails.

So what is the solution to this problem

1.relevance- Keep relevant Feature on Board.

As already noted, keeping a valuable feature in the application make your application small in size and easy to fix bugs more often and easy to maintain. (Customer/user Focused).

2. Maintainability- if maintaining software is hard then definitely it brings many more problem onto the table. So Maintainability means Understanding the code more quickly with respect to the context on which domain you are solving a problem or fix a bug, introducing a new Feature to the application should be more often happens in the projects. So the System should always be able to extend or ready for a change. So maintaining software takes a key part in Designing software.

5.keep a Quick FeedBack Cycle.

Quick feedback most often very valuable in developing software.

It helps us more often to get away for what we are intended to so.

a). Lack of Communication - Lack of communication between the team of developers or the domain experts are most often misleads design what it is actually wanted to perform its a serious thing to take it to the consideration. Because it cost lots of money, time, manpower etc. Defiantly stating a problem which is intended to do a certain task on the existing system on a defined context/domain is the fundamental one to be done by every individual developer.

One of the practical eg for this is I was once gone to Java-meetup a Senior developer who works on Java SDK noted that they spend generally around 5 to 8 lakhs Rupees (6K to 10k $ ) to fix a Bug which comes from outside the Organisation. a bug will cost them time and money if they get noticed the bug most earlier they would save the Both money and time by four folds.

So what’s the catch here how to approach it.

b). Release more often- Checkin your code more often and test whether the change you are made works, as intended to be that, gives us quick feedback like a change you made does it reflect the existing code base or the change in some code results in break the existing code base. this quick feedback will give us a perspective and confidence in moving in the right direction(most of the times).

c). Run Tests more often-Once you have finished most of your time on solving a problem run test cases more often this will give us even more quick feedback to come to the conclusion that the software is behaving it is supposed to. If the test fails that gives us the feedback of point at which we are gone wrong.

6. Keep Design Simple.

Yes, it is very easy to type that heading. What does the simple mean? how to achieve the mantra of Simple design. It takes lot of thoughts , time ,efforts to design a some piece of code.that would defiantly save the future us if we are working on the same project we often thought who the hell in this world written a piece of code and try to fix it defiantly a poor design or poor coding practices it is just like a karma what we wrote definitely hunts us down the line because we have worked on code written by others.

So as we know a System said to be Simple Design when it has the below things 

1.Easy to understand

2.Minimal.

3. Fails more Often.

4.High Cohesion less Coupling.

5.Easy to maintain.

6. less Cost

7. Effect-less upon the changes introduce (Cost of change should be minimal).