Thursday, January 30, 2014

Develop with Pleasure!

1. Users Stories: From subject matter experts (SME), either write it down or get it from business analysts (BA). Don't keep stories too big. if they happened to be then split them into small. Take help from BAs to split it into small.

2. User Cases: Extract the use-cases and list them out.

3. Identify the happy path which completes the story/use-case and start with one at a time.

4. Extracting the Business Logic and Rules from the above.

5. Create a solution structure, and a project under source control system.Store everything under source control. No documents or test cases or supporting documents & software libraries and tools should be outside the source control. Even if you keep micro-notes of your workflow in attacking the story should also be in the source control.

6. Transform above into corresponding Acceptance and Unit Tests. Automate them using automation tools and frameworks. Need not to write all of them at once but acceptance criteria tests can be completed story-by-story, case-by-case.

7. Reading a set of acceptance and unit tests should tell the same Story and be traceable back to the original story/use-cases.

8. Make unit tests pass one-by-one. If needed add more tests to complete the corners cases. No single line of production code (either feature or bug-fix) should be written without a corresponding failing test.

9. Keep all the assets always checked-in. Check-in your code frequently. Don't check-in incomplete, non-compilable code. If you want then use shelving feature to store incomplete works.

10. Every step/changes (feature, bug-fix) should be checked-in separately. Don't work on more than one thing at a time and check-in all at once. It would be very difficult to write check-in comments when multiple items are checked-in. Write good check-in comments.

11. Don't check-in without passing all the units tests in your machine. Always get latest version, rebuild the solution, make sure it compiles, and all the units tests are passed. Repeat this until you get all the tests are passing.

12. Refactor the code frequently. Follow... Red...Green-Refactor path.

Develop with pleasure! :)

Wednesday, January 29, 2014

John A Zachman on Architecture

John A Zachman, Pioneer of enterprise architecture and  originator of the "Zachman Framework". 
A quote in the preface of his book: 

"If you get really honest and search all of history, seven thousand years of known history of humankind, to find out how humanity has learned to cope with two things, complexity and change, there is one game in town: ARCHITECTURE.

If it (whatever it is) gets so complex you can’t remember everything all at one time, you have to write it down …  ARCHITECTURE. Then if you want to change it (whatever it is), you go to what you wrote down … ARCHITECTURE.

How do you think they build hundred-story buildings or Boeing 747’s, or IBM supercomputers … or even simple things like a one-bedroom house or a Piper Cub or the PC on your desk?

Somebody had to write it down … at excruciating levels of detail … ARCHITECTURE. Now, if you want to change any of those things (with minimum time, disruption, and cost), how do you change them? You go to what you wrote down … ARCHITECTURE. The key to complexity and change is ARCHITECTURE."

I'm just thinking about it...

Monday, January 27, 2014

Test automation would be your system's knowledge source

Manual testing (whether it is developer/unit level testing, or acceptance testing or even system level integration testing) has one one major problem (though it has some advantages). Software testing involves gathering lot of knowledge about the system associated with on what the system should do and should not do. It involves domain knowledge, business processes, business logic, business rules, workflows etc.

Over the time of system's development life-cycle, this knowledge is elicited, gathered and acquired by the development team and used to build the system. On certain things, even business owners/stakeholders also gets enlightened over the time period during the course of system development which they forget why such a decision was made to build the way it is behaving today.

Using this system knowledge, the testing team constantly verifies and informs the developers and make sure the system is doing what it should be by testing the interdependent modules time-to-time. This knowledge of what the system should do and should not do (business processes/logic/rules etc.) will reside in developers' minds and majority would be in testers' mind. It spreads across the team members.

And the problem is "If they leave the organization, the knowledge walks out with them". It will take considerable amount of time to extract them from the code. There will be huge amount of effort goes in this task. Meanwhile if system maintenance would be jeopardized.

Over the time, as system getting growing and getting big, it would also very difficult to carry everything in mind!!!

It would be very difficult to document these and keep updated. They can any point of time go out of date. The most up to date document is source code. Referring outdated documents are even danger than no documents. It can put into wrong direction. Code comments are also the same.

With automation, the system can be documented and kept up to date all the time. We can easily identify the tests not in use and remove them. Any members who joined lately and testers can easily make changes to the system without any fear of breaking it. This way one can easily change the system over the time and kept it update. It would also very easy to read the tests and understand it.

So try automating the system testing as much as possible.

There are some caveats in automating everything that would be a topic of another post.

Sunday, January 19, 2014

On Agile and Agility

Several times I now hear that agile become a normal thing in software development. Well I don't know fully whether that is correct or not but I see the word "Agile" appears (as either suffix or prefix) on everything including company names, product names, project names, template names, and even resumes'.

Is it really become a normal practice in every software company now? Are they really agile without implementing the underlying practices? In these days, by default, people are using Agile word in place of Quality like instead of calling "Tooth Paste" calling it "Colgate" or like Xerox to a Photo Copy.

I see any new term introduced in software technology becomes very soon a buzz word and its importance gets polluted with over using it. Sometimes its meaning and purpose also changes in some contexts. People starts using them for fancy reasons to add more effectiveness into their things (speech, works, resumes, products and projects etc.) For example code Refactoring in software development is used by many things when they refer code quality without knowing what it is.

I observed and asked many developers what it is? when they say I'll have to Refactor it. They say we've a Sprint for Refactoring and they change the code to fix bugs and add new features etc. Sometimes the word itself is misleading people because its very easy to give another meaning without knowing and thinking about it.

Nevertheless, Agile also been started using in many contexts without real understanding and knowing it fully.

Tuesday, January 14, 2014

Object != Class

Many developers write procedural code in object-oriented languages like Java and C#. Telling them "write object-oriented code" is very easy than implementing it, especially for three classes of developers.

1. Interns and novices who don't know exactly what it is and not have sufficient practical knowledge.
2. Experienced developers but never got it right. Nobody told them that whether it is correct or not by reviewing their code base
3. People came from other engineering stream and curriculum for example studied non-computer science groups and entered into software development without having a formal training etc.

The theory they learned and the examples they used in academics are not enough to know the differences. The examples they used for practicing are vary depending the stream they studied. For example: Engineering stream and IT stream. Engineering stream uses technical examples. IT stream uses the business information processing example. It is easy to understand them from real world examples like Birds, Animals, Geometrical Shapes etc. but it is very hard to apply these principles and techniques in business entities and information processing etc.

Classes are blue prints of objects.  Objects are instances of those classes having an Identity, State, and Behavior. Objects are collections of roles and responsibilities. Objects play roles and roles will have responsibilities to carry-out some job. Objects are mostly about behavior to carry out some task. They are not bundles of data. The object’s state should be always hidden from the outside the world.

Decomposing and distributing the responsibilities among small-small objects is an art that should be deliberately practiced over and over and constantly reviewed to know whether there are multiple things in going into single object.

I’ll write more in detailed on this subject in coming posts.

Difference between Procedural, Object-Based and Object-Oriented Approaches

Assume we need to develop a software that manages room temperatures by applying heat in to the rooms when necessary. The basic business is that each room has a desired temperature and current temperature. If the current temperature is lower than the desired temperature, then heat must be pumped into the room. But, if no one is there in the room, then temperature can be left to fall to 10 degrees below the desired temperature.

Procedural Approach:

We can write a HeatFlowRegulator program that gets the current & desired temperature for a given room number, and then a boolean to indicate whether anybody there in the room. The program then decides if heat should be applied in to the room or not.

Object-Based Approach:

We can write a HeatFlowRegulator program that gets a Room object and asks the object for its current & desired temperature and whether anybody there in the room or not. The program then decides if heat should be applied to the room or not.

Object-Oriented Approach:

We can write a HeatFlowRegulator program that gets a Room object and asks the Room object if it needs heat or not.

Hope the above example helps in showing the difference.

There is a principle called "Tell. Don't Ask" states that don't ask the object for its internal state and do take decisions based on that instead tell the object to do the things for you. In the above example the 2nd approach asks the object about its internal state and takes decision.

There is one more example I read somewhere sometime back on "Paper Boy". Paper Boy will always presents a Bill and requests the money to pay the paper bill rather than directly pulling your wallet and taking the bill amount needed.

It'll become very hard for object to change its internal representation if consumers tightly couple the code to its' internal state.

Monday, January 13, 2014

On Exception Handling

Exception Handling:

A) Never swallow the exceptions in catch block: Catching exceptions and swallowing is very danger than not catching them. This counter impacts the quality. If you don't want to process the exceptions then don't unnecessarily catch it. There are few very rare cases to swallow an error but it should be justified.

B) There can be 5 reasons to catch exceptions: The following can be reasons for wrapping a code fragment in a try...catch block:

  1. You want to recover from it by retrying the operation 
      for example a database server connection. Want to connect to alternate server.
  2. You want to add some extra information in to the exception you have catched and re-throw
  3. You want to cleanup some resources in finally block
  4. You want to ask the user what to do by providing some possible options.
  5. You want to log the full error stack and display a fancy message to the user

C) Exceptions are expensive in terms of performance. Don't drive the whole business logic with just exceptions. Where possible pre-check the possible error conditions and throw the exceptions.

D) Don't use error codes to like 1001, 1, 2 etc. to return an error states. User's of those methods can fail to check for them. For example there can be a possible null or divide by zero then check for them and throw the exception.

E) Create your own exceptions derived from framework's Exception base class and use them to drive and enforce the business logic, rules and policies.

F) Always wrap the higher level (top most where the code execution entry points) methods in a try...catch block. For example: all event handlers in a Win, WPF, Web Form application. The service entry points for Web service, Web/REST API services. This is means catch only the boundaries.

I'll do more posts with thorough and detailed examples.

Monday, January 6, 2014

On automated unit testing

1. Code that is test harnessed with automated unit testing (or developer testing) is like the money we have given to somebody on interest. We get interest on it as we go over the time of the project.

2. Code that is NOT test harnessed with automated unit testing (or developer testing) is like we borrow the money from others on interest. We've to pay with interest as we go over the time of the project. This interest is time and money we pay in fixing the bugs created in adding more feature. Every time we add new code or fix the bugs we need to test associated the code to know something is not broken. This is even worse when we refactor the code base to improve the internal structure to make it more changeable. Code refactoring without the automated unit tests is very difficult and time consuming.

So Automated unit tests are earnings (interest of time, money and energy). Without this we have to pay this interest.

Testing != Debugging

Today, I came to hear an interesting thing. A SharePoint developer came to me to know and fix an error. I asked how to test that this is not working. I asked how do you test your code. He then replied saying that I hook/attach the process and then I debug. I said I'm not talking about debugging the code but I want know how do you test. He just got confused and said this is how I test. I said OK. That is really you're tracing and debugging the code line by line but not testing.

SUT (system under test) is directly running from the UI. There are some web parts and one of the web part is is calling a class that actually do the work. They write the code in here and there (UI events and some classes in back-end), every time they need to test they deploy it and run the application and attach a UI process to test it if it is not going to work.

For lot of programmers testing means debugging. Actually a "developer testing" is not debugging.

Friday, January 3, 2014

Simple Object Patterns

Over the time in next few months, I would like to share and discuss topics related to object-oriented design, patterns and principles. There can be many but I would like to focus mostly from the implementation perspective. Some times it's easy to read about this Object-Orientation things but practically it is difficult to apply in some cases. I see some patterns and principles are good to read from its description and appears very easy to apply in specific problem domain. But when we see similar problem in our own examples, and try to apply, then it becomes very hard.

I would also like to share some of my own practical experiences, problems and challenges I faced from my day-to-day job in designing information systems.

I'll post them under the title "Simple Object Patterns"

True qualities of leadership

Practically I find the following qualities useful in leading people around you

1. Sacrifies
2. Protecting the Team
3. Guidance
4. Mentoring

Managing a problem will not solve from the root. Managing is temporary solution