Tag Archives: Agile

Design before you code

Somehow, with the penetration of agile development practices, I have been observing that less and less time is spent on designing the solution. Engineers treat Agile as a license to develop without design.

What is the problem with developing without designing or architecting the system first? I still remember when I was in college, my professor drew a parallel between architecting a building and architecting a software. Would you start building a house without thinking about design? you will not just start placing bricks without considering how many rooms you need? Where all these rooms go? How large should be every room? Where will the kitchen and bathroom be? Where all the wiring and plumbing will go? You will come up with the design, put in on a paper or a software and then calculate the feasibility.

Think of the complications that can happen if you build your house without thinking about design first. One room might be so big that there is very little space for the others. Or you are not left with any space to create a bathroom. These mistakes are costly. And that brings me to the other important factor which is causes ignoring of design in software. The manager thinks that change at a later state is going to be easy. At the end it is code, we can just change it. Well, changing the code is definitely possible, but never easy or cheap. It comes with its own cost.

More than often, where developers need to make changes at a later stage, they would be more inclined to apply quick fixes or hacks rather than making a bigger correct change. Of course, you have a tried and tested code in hand, why would you make too many changes to it, even if you know that is the right thing. And then there is developer ego, I mean, let’s admit it, it is not easy to accept one’s fault, especially if that means you would need to put in extra hours to fix that. More than ego, it is actually denial at times. People would try to stick to the solution they developed initially even though it is realized at a later stage that there could have been a better solution. Reason being, you have already invested too much.

This situation can be avoided if we think about design first. We can make sure our design covers all the possible requirements. It will not be possible to anticipate all the changes that are going to come at a later stage, but we can try to keep our design flexible. The idea is, set the ground rules, understand what all component and services we are required to create? What all data needs to be persisted and how are we going to do that? How security and error handling will be done? We need not get into implementation details, but the high-level design is a good start. We can fill in the details as and when requirements are clearer and we start actual work on the given piece of requirement.

In the end, all I would like to highlight is, if you think you are saving time by not thinking about the design of the application before you start to code, you are going to end up spending more time applying patches and fixes at the end.

Krutchen 4+1 Architectural view model- Agile perspective

I have a strong belief that Solutions Architecture is as much of a science as it is an art. There is no set of fixed rules you can apply to get a final architecture. There are rules, but they can get changed based on kind of project, teams and constraints you are working with.

Coming to 4+1 Architectural view of software architecture, Krutchen shared an interesting way of looking at software architecture in this paper.

Original paper- https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf

In crux, the paper suggest that we can look at any software architecture from 4 perspectives or views to get a complete picture.

Logical view: This is end user view of the system. How many entities or classes are there and how they interact, for example, how Employee will be related to Department and Project, what will happen when someone joins or leaves an organization.
UML: Class Diagrams, State Diagrams.

Process View: This talks about how the business works as a process. If you need to open an account in a bank, what process needs to be followed. In addition, we take care of non-functional requirements like scalability, performance etc in this view.
UML: Activity Diagrams

Development View: This is a view for developers, understanding how the system will be implemented (also known as implementation view). How many components will be created and how will they interact with each other.
UML: Component Diagram, Package Diagram

Physical View:
This view explains how this system will be deployed physically. What kind of machines are there and how these are interacting.
UML: Deployment diagram

Scenarios: Scenarios or Use cases are given special attention. Because before getting into any other views, one needs to understand all the use cases we need to handle for the system being developed.

Well the paper explains about these views in details, so here I would like to add my understanding of how to use this model in agile development methodology.

Agile Perspective:
When you are building a software in agile manner, you are taking up one use case at a time, broken down in form of stories. Once you have sorted out what all use cases are you dealing with in current sprint or cycle, you can start by understanding logical view for these cases. Moving on to Process view then Development view and finally Physical view, case by case. So rather than creating the whole picture in one go, we will be creating our architecture as and when we are working on a particular use case.

Understanding Agile

I have heard many versions of people defining Agile development. I met someone who claimed that they use Agile development in their project. When asked how can they say they are doing Agile development, it was told that team meets in the morning everyday to discuss status and hence the project is using Agile development.

I have also heard people talking about Agile development in a manner that it will automatically solve all your development problem, they do not realize if not implemented properly, Agile development methodologies can actually backfire. Others confuse Scrum with Agile development, well they are not completely wrong, but one needs to realize Scrum is a Agile Framework like Kanban, Extreme Programming, SAFe etc.

Keeping it simple, lets take a quick look at Agile manifesto.
http://agilemanifesto.org/

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

And then 12 principles
http://agilemanifesto.org/principles.html

We are talking about focus on customer satisfaction, continuous delivery, accommodate changing requirements, frequent collaboration between Business and development teams, focus on people than on processes, more focus on face to face and frequent interactions, focus on working software, reflect on current processes frequently and self improvements.

One thing to note is Agile development methodologies or manifesto nowhere gives a series of steps or rules. These are guidelines, which one need to apply to ones project. This will definitely help but there is no silver bullet. There are Agile frameworks and methodologies as mentioned above, but you still need to figure out what will work for you rather than blindly following some document or advice of a so called expert. Best way is to look at as many methodologies and frameworks as possible, pick up the practices which you feel will work for you, and keep on validation after a short period what is working and what does not.

Agile Mobile Development

One of the best candidates for agile development I have found is mobile app development. Why?

1. Requirements are usually not very clear as mobile app development itself is relatively new- so client demos and regular feedback helps us not to move away from what is required.

2. The mobile technologies have not been explored as much as we have already explored web technologies, so we still have lot of challenges to be faced. This means peer reviews and pair programming can be very helpful.

3. The apps are generally UI extensive, that means they are good candidates for client feedback. We need to get clarity on look and feel, and specially responsiveness of the app.

4. With frameworks like phonegap available and newly emerging augmented reality libraries, complex mobile apps are normally started in POC (proof of concept) mode. With hit and try approaches, it is good to have daily discussions to float ideas and get feedbacks within the teams.

Refer : http://kamalmeet.com/2013/06/agile-development-what-is-it/
http://kamalmeet.com/2013/06/agile-development-is-it-for-me/

 

Agile Development- Is it for me?

Agile practices are becoming popular day by day. In my last post I took up the question Agile Development- What is it? But the important question for a development team or manager should be Agile development- Is it for me? Is it the right choice? Should I use it just because it is working for someone else?

Every coin has 2 sides and so does agile methodology. If there are benefits of using it, it can also hurt the development process if not used intelligently. For example, if a project does not have many UI elements and has more complexity at backend like handling of MDBs and Web Services, having a client demo every week will not be very useful as we will not have anything new to demonstrate. Similarly, if the requirements are mundane and team has already worked on similar requirements already, pair programming will cause a negative impact on productivity.

While going for the agile approach, we will need to analyze if it will work for project in hand, rather than trusting it blindly. Ideally we should be checking each agile practice in detail and see if this is something I can use, and not go for the complete package.

For Example:

Continuous Client Feedback: If my requirements are not very clear, or are prone to changes or software has heavy UI element which needs to be verified by client, I should definitely plan weekly or biweekly demos based on project complexity and requirement.

Test Driven Development: Need to analyze how much automated test scripts will be required. Black box and white box test cases needs to be analyzed. Test cases can be created in parallel of code rather than before coding starts. If requirements are prone to change it might not be useful for me to create automated test scripts beforehand.

Face to Face Communication: if we are working in a model where teams are scattered across globe, we will not be able to follow this. Conference calls might be helpful.

Pair programming: In case we are working on a cutting edge technology which is new to team and having more than one mind concentrate on a problem will help, this is definitely the way to go.

Similarly we will need to take a call on what will work for my project rather than following the herd and going agile mindlessly.

Agile Development- What is it?

Human beings by nature are impatient. That reflects in software development industry as well now. Gone are the days when it used to take years to complete software, now we are talking about software delivery in months and at times in weeks. Due to this impatience, we are seeing a lot of emphasis on agile development practices.

Agile– the term means fast, quick. So we are looking for some way to fasten up our software development process in order to reach the end results quickly. Here are some key components of agile methodology which help us speed up development process

Iterative Development: Rather than following traditional waterfall model, we will get into more spiral mode. The idea is to divide the final requirements into small junks, where each chunk can be delivered one by one, in each iteration.

Continuous Client feedback: This is the most important factor in agile development mode. We do not wait till the end to get the product completed and then get it reviewed from client. The idea is to involve client at every stage by giving weekly or bi weekly demos of the product so that everyone is on the same page and last minute surprises can be avoided.

Test Driven Development: see here.

Emphasis on Face to Face communication: In a normal scenario, where development teams are sitting in different geographical locations, communication will flow through emails. And a query raised from one team will most probably take a day or two to get resolved. This delay can be a killer of agile development, so focus is laid on having team sitting close to each other.

Daily status meets: Generally a short meet of 10 to 30 minutes is scheduled every day where focus is on – previous day’s achievement, today’s plan and any issues being faced. This helps keep the team on track and use knowledge of whole team to solve any issues.

Pair Programming: Slightly controversial practice of2 people sitting together on a machine and writing the code. This is very tricky to implement as if team is not educated on the pair programming activity, we might end up losing productivity that two people are doing work of one.

The list is not exhaustive. Ideally there can be no complete list as every team should invent best practices of its own, of course keeping the tried and tested methodologies as the base.

Test Driven Development

One of the most important practices of Agile development process is Test Driven Development (TDD). It is not a complex term to understand, TDD simply means you are aware of test cases before you actually start development of a piece of code. You are supposed to write test cases, automated test scripts, Junit test suite before you actually went on to write the real code.

Though the concept is simple, but in real world the implementation is not that easy. Why? Lets look at some of the key challenges.

Challenges for TDD

1. How can you create a test plan for something which does not even exist?
2. What if Requirement gets changed or modified? Instead of just making code change, we are making change to test plan as well. If we were creating tests after code completion, we will have saved ourselves from the trouble of making the changes to test plan.

Ok we have talked about the challenges, so why should we take so much pain and not just stick to the regular practice of writing test cases after writing the code.

Advantages of TDD

1. You can test the code implementation the moment you have written it without waiting for the test to be ready as the test was written before code.
2. Errors are caught at the early stage rather than propagating till late stages.
3. Test cases can be confirmed by business team, so that any discrepancy in the requirements can be figured out at an initial stage.
4. Most importantly, a TDD makes sure improvement in code quality. As the test cases are written in advance, it makes sure that all the code written passes the test before getting checked in.