We continue to use and reuse code that is no longer maintainable because it still works in some way and we are afraid to modify it. When we remove redundancy, eliminate unused functionality, and rejuvenate obsolete designs it means we are refactoring. Refactoring throughout the entire project life cycle saves time and increases quality. Refactor allows you to keep your code clean and concise so it is easier to understand, modify, and extend. Make sure everything is expressed once and only once.
Why Refactoring?
Refactoring allows a rapid development process and simple code structure while maintaining clean, scalable, and modular code.
1. The meaning of the code should be obvious to anyone reading it. Comments can be added as well for providing additional explanation to the code, but one should try to make the code itself clear enough to understand.
2.Eliminate redundant code: Refactoring is the time to recognize patterns and factor them out of your code. Similar and redundant classes and code blocks should be combined, and unnecessary functions and variables eliminated.
3. Modularity and Scalability: Code should be easy to extend or modify, and be able to scale without adding complexity
Implementation issues
Refactoring means having to go back over one's own code. Especially when deadlines loom, working code is often assumed to be good-enough code. Refactoring can become another post-process like internal documentation that everyone recommends but that few programmers actually have the time to perform. As Cooper puts it in Extreme Programmming vs. Interaction Design, "There's enormous cost in writing code, but the real cost in writing code is that code never dies. If you can think this stuff through before you start pouring the concrete of code, you get significantly better results."
This can be addressed through several means. If code is kept simple, then going back over and having to understand everything again is significantly easier and the programmer is more likely to do it.
References:
http://www.exciton.cs.rice.edu/comp410/XP/refactoring.html
Friday, December 28, 2007
Requirements Change and Agile
1. Requirements are ought to be changed. What might be a good set of requirements now, is not a good set in six months time. Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable.
2.It does not mean the predictability of software development is impossible. But it requires a lot of ceremony, plenty of time, a large team, and stable requirements :)
3. Most of the time, this is not the case. So how to overcome or control an unpredictable process? this can be done with the help of iterations. These small iterations (working systems and as short as possible in time) are short on functionality, but should otherwise be faithful to the demands of the final system. They should be fully integrated and as carefully tested as a final delivery.
4. Iterative development makes sense in predictable processes as well. But it is essential in adaptive processes because an adaptive process needs to be able to deal with changes in required features. This leads to a style of planning where long term plans are very fluid, and the only stable plans are short term plans that are made for a single iteration. Iterative development gives you a firm foundation in each iteration that you can base your later plans around.
5. The important and interesting question comes here is, if the software development is unpredictable, then how can we make cost estimations? A fixed price contract requires stable requirements and hence a predictive process. Adaptive processes and unstable requirements imply you cannot work with the usual notion of fixed-price. Trying to fit a fixed price model to an adaptive process ends up in a very painful explosion and this will put both the software development firm and the client in loss. But it does not mean you can't fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner.
6. Adaptive process leads to good advantages to the customer.
a. Client receives much more responsive software development.
b. A usable, although minimal, system can go into production early on.
c. The customer can then change its capabilities according to changes in the business and also from learning from how the system is used in reality.
7. In the adaptive approach, you need to to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren't so important, only the roles are important. Btu at the same time you have to make sure that people are not completely treated as resources, and they have to be mentored and you have to make them realize that there are very important to the project.
8. Developers needs lot of discipline to execute the process. Developers must be able to make all technical discussions. Such technical leadership requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Management still plays a role, but recognizes the expertise of developers.
9.Technical people have to recognize that entering management means their technical skills will wither rapidly. Ex-developers need to recognize that their technical skills will rapidly disappear and they need to trust and rely on current developers.
10. Agile teams cannot exist with occasional communication. They need continuous access to business expertise. Furthermore this access is not something that is handled at a management level, it is something that is present for every developer. Since developers are capable professionals in their own discipline, they need to be able to work as equals with other professionals in other disciplines. A large part of this, of course, is due to the nature of adaptive development. Since the whole premise of adaptive development is that things change quickly, you need constant contact to advise everybody of the changes.
11. A project that begins using an adaptive process won't have the same process a year later. Over time, the team will find what works for them, and alter the process to fit.
The first part of self-adaptivity is regular reviews of the process. Usually you do these with every iteration. At the end of each iteration, have a short meeting and ask yourself the following questions
* What did we do well?
* What have we learned?
* What can we do better?
* What puzzles us?
These questions will lead you to ideas to change the process for the next iteration. In this way a process that starts off with problems can improve as the project goes on, adapting better to the team that uses it.
While both published processes and the experience of other projects can act as an inspiration and a baseline, the developers professional responsibility is to adapt the process to the task at hand.
References:
http://www.martinfowler.com/articles/newMethodology.html
2.It does not mean the predictability of software development is impossible. But it requires a lot of ceremony, plenty of time, a large team, and stable requirements :)
3. Most of the time, this is not the case. So how to overcome or control an unpredictable process? this can be done with the help of iterations. These small iterations (working systems and as short as possible in time) are short on functionality, but should otherwise be faithful to the demands of the final system. They should be fully integrated and as carefully tested as a final delivery.
4. Iterative development makes sense in predictable processes as well. But it is essential in adaptive processes because an adaptive process needs to be able to deal with changes in required features. This leads to a style of planning where long term plans are very fluid, and the only stable plans are short term plans that are made for a single iteration. Iterative development gives you a firm foundation in each iteration that you can base your later plans around.
5. The important and interesting question comes here is, if the software development is unpredictable, then how can we make cost estimations? A fixed price contract requires stable requirements and hence a predictive process. Adaptive processes and unstable requirements imply you cannot work with the usual notion of fixed-price. Trying to fit a fixed price model to an adaptive process ends up in a very painful explosion and this will put both the software development firm and the client in loss. But it does not mean you can't fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner.
6. Adaptive process leads to good advantages to the customer.
a. Client receives much more responsive software development.
b. A usable, although minimal, system can go into production early on.
c. The customer can then change its capabilities according to changes in the business and also from learning from how the system is used in reality.
7. In the adaptive approach, you need to to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren't so important, only the roles are important. Btu at the same time you have to make sure that people are not completely treated as resources, and they have to be mentored and you have to make them realize that there are very important to the project.
8. Developers needs lot of discipline to execute the process. Developers must be able to make all technical discussions. Such technical leadership requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Management still plays a role, but recognizes the expertise of developers.
9.Technical people have to recognize that entering management means their technical skills will wither rapidly. Ex-developers need to recognize that their technical skills will rapidly disappear and they need to trust and rely on current developers.
10. Agile teams cannot exist with occasional communication. They need continuous access to business expertise. Furthermore this access is not something that is handled at a management level, it is something that is present for every developer. Since developers are capable professionals in their own discipline, they need to be able to work as equals with other professionals in other disciplines. A large part of this, of course, is due to the nature of adaptive development. Since the whole premise of adaptive development is that things change quickly, you need constant contact to advise everybody of the changes.
11. A project that begins using an adaptive process won't have the same process a year later. Over time, the team will find what works for them, and alter the process to fit.
The first part of self-adaptivity is regular reviews of the process. Usually you do these with every iteration. At the end of each iteration, have a short meeting and ask yourself the following questions
* What did we do well?
* What have we learned?
* What can we do better?
* What puzzles us?
These questions will lead you to ideas to change the process for the next iteration. In this way a process that starts off with problems can improve as the project goes on, adapting better to the team that uses it.
While both published processes and the experience of other projects can act as an inspiration and a baseline, the developers professional responsibility is to adapt the process to the task at hand.
References:
http://www.martinfowler.com/articles/newMethodology.html
What are the things require to go for Agile?
1. The first step is to find suitable projects to try agile methods out with. Since agile methods are so fundamentally people-oriented, it's essential that you start with a team that wants to try and work in an agile way. Not just is a reluctant team more difficult to work with, imposing agile methods on reluctant people is fundamentally at odds with the whole notion of agile development.
2. It's valuable to also have customers (those who need the software) who want to work in this kind of collaborative way. If customers don't collaborate, then you won't see the full advantages of an adaptive process. Having said that we've found on several occasions that we've worked with customers who didn't want to collaborate, but changed their mind over the first few months as they begun to understand the agile approach.
3. Some people advise picking a project with little business impact to start with, that way if anything goes wrong then there's less damage. However an unimportant project often makes a poor test since nobody cares much about the outcome. I prefer to advise people to take a project that's a little bit more critical than you are comfortable with.
4. Perhaps the most important thing you can do is find someone more experienced in agile methods to help you learn. Whenever anyone does anything new they inevitably make mistakes. Find someone who has already made lots of mistakes so you can avoid making those yourself. Again this is something true for any new technology or technique, a good mentor is worth her weight in gold.
So where should you not use an agile method? I think it primarily comes down the people. If the people involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. In particular I think that this means you should never try to impose agile working on a team that doesn't want to try it.
2. It's valuable to also have customers (those who need the software) who want to work in this kind of collaborative way. If customers don't collaborate, then you won't see the full advantages of an adaptive process. Having said that we've found on several occasions that we've worked with customers who didn't want to collaborate, but changed their mind over the first few months as they begun to understand the agile approach.
3. Some people advise picking a project with little business impact to start with, that way if anything goes wrong then there's less damage. However an unimportant project often makes a poor test since nobody cares much about the outcome. I prefer to advise people to take a project that's a little bit more critical than you are comfortable with.
4. Perhaps the most important thing you can do is find someone more experienced in agile methods to help you learn. Whenever anyone does anything new they inevitably make mistakes. Find someone who has already made lots of mistakes so you can avoid making those yourself. Again this is something true for any new technology or technique, a good mentor is worth her weight in gold.
So where should you not use an agile method? I think it primarily comes down the people. If the people involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. In particular I think that this means you should never try to impose agile working on a team that doesn't want to try it.
Open source vs Closed source software
Opensource software is a software where users will have access to the source code. Users can view the code and modify according to their business needs.
Regarding Closed source software, you never know what kind of code had been written. Users will not have access to the source code. Users can only have access to use the software.
Is access to source code generally required?
Mostly No. Not most of the users bother to view source code. They need the application working.
But what if the user wants to change colors or wordings,?
In this case, having source code is defnitely an advantage. Access to source code defnitely gives you points over not having source code at all.
What if user tries to modify the source code without having full knowledge of it?
The application corrupts and may not work. There is a channce that your application is corrupted by changing code without an idea. You need to make sure the access to source code is restricted to only to those people who have knowledge of it. This is nothing but one sort of closed source in open source software.
Overall, No one scores over other. Closed source software is something which is there from the beginning or popular from long time. Open source software is the innovation or something which is upcoming now. Comparing both these is not actually a good idea, because one is opposite to other. Disadvantages of one is advantages of the other one. So there is no question of comparison. Both are good and useful in their own ways.
Regarding Closed source software, you never know what kind of code had been written. Users will not have access to the source code. Users can only have access to use the software.
Is access to source code generally required?
Mostly No. Not most of the users bother to view source code. They need the application working.
But what if the user wants to change colors or wordings,?
In this case, having source code is defnitely an advantage. Access to source code defnitely gives you points over not having source code at all.
What if user tries to modify the source code without having full knowledge of it?
The application corrupts and may not work. There is a channce that your application is corrupted by changing code without an idea. You need to make sure the access to source code is restricted to only to those people who have knowledge of it. This is nothing but one sort of closed source in open source software.
Overall, No one scores over other. Closed source software is something which is there from the beginning or popular from long time. Open source software is the innovation or something which is upcoming now. Comparing both these is not actually a good idea, because one is opposite to other. Disadvantages of one is advantages of the other one. So there is no question of comparison. Both are good and useful in their own ways.
SCRUM Process
Some information on SCRUM processes.
SCRUM is like an agile process for developing software. It mainly focusses on delivering the work. SCRUM is ideally suited for the projects where the requirements were changing rapidly. The SCRUM values are mainly derived from the agile values of software development.
SCRUM process mainly runs through these 4 steps. Every task/tasks in the project will go through these 4 steps.
1. Develop
2. Wrap
3. Review
4. Adjust
The SCRUM process has 3 main phases
1. Planning
2. Sprint Cycle : This cycle will be of 3-4 weeks. This is the period where actual development takes place. At the end of the cycle, it will be reviewed and adjustments are made to the project, if necessary. This will be continuing until the project is completed.
3. Closure: Project/product development will be closed and the product will be released.
In SCRUM process, there will be a SCRUM Master, who is a team leader and also one of the member of the team doing the project.
SCRUM process also states to have daily meetings. It would be good and ideal to have meeting after the lunch break. Since all the members have already started work in the morning, the team will be more focussed on the task and can get more inputs/comments. Meeting will be mainly focused on 3 points
1. What had we achieved
2. Any obstacles
3. Next team objectives
Related links:
http://www.codeproject.com/gen/design/scrum.asp
http://www.mountaingoatsoftware.com/scrum/
http://www.controlchaos.com/about/
SCRUM is like an agile process for developing software. It mainly focusses on delivering the work. SCRUM is ideally suited for the projects where the requirements were changing rapidly. The SCRUM values are mainly derived from the agile values of software development.
SCRUM process mainly runs through these 4 steps. Every task/tasks in the project will go through these 4 steps.
1. Develop
2. Wrap
3. Review
4. Adjust
The SCRUM process has 3 main phases
1. Planning
2. Sprint Cycle : This cycle will be of 3-4 weeks. This is the period where actual development takes place. At the end of the cycle, it will be reviewed and adjustments are made to the project, if necessary. This will be continuing until the project is completed.
3. Closure: Project/product development will be closed and the product will be released.
In SCRUM process, there will be a SCRUM Master, who is a team leader and also one of the member of the team doing the project.
SCRUM process also states to have daily meetings. It would be good and ideal to have meeting after the lunch break. Since all the members have already started work in the morning, the team will be more focussed on the task and can get more inputs/comments. Meeting will be mainly focused on 3 points
1. What had we achieved
2. Any obstacles
3. Next team objectives
Related links:
http://www.codeproject.com/gen/design/scrum.asp
http://www.mountaingoatsoftware.com/scrum/
http://www.controlchaos.com/about/
Object Orientedness in Web applications
The important aspects of Object Oriented Programming is as follows
1. Encapsulation : Data security
2. Polymorphism : One function several uses
3. Inheritance : Write once, use many times
Web has evolved into a global environment ranging from small scale to large scale and enterprise workflow systems. But still the approach towards web application is very ad hoc. It is not in a structured way. Some of the web frameworks support object orientedness, but to a very limited extent. In some frameworks, you can achieve Encapsulation by concept of namespaces or Inheritnace by reusing the available procedures. The concept of object orientedness is present in many web application frameworks, but it is not in a fully structured way.
OOPs concept in web applications
Encapsulation: It can be achieved in the form of classes and access specifiers. The functions defined in the class will not be accessible from outside the class unless it is explicitly defined as public. This way we can achieve better security and can be guaranteed that your code is in control of you and also in a structured way. I say structured because all the code related to one particular module is at one place i.e in a Class.
Polymorphism and Inheritance: These two work in align with each other. Assume we have an class called "Validate" which takes care of validations of some text fields. I can reuse the same functionality in my other modules with the concept of inheritance. Once I inherit the Validation class, I will have all the functions and variables available in my sub class and i dont need to write validation again for my module. I can reuse the available functions.
If my module requires more functionalites or changes in existing functionality of the module, then I can overwrite the function in my subclass. This way we can achieve polymorphism.
So on onverall, object oriented concept will defnitely help a lot in web applications and will ease the job of the developer.
1. Encapsulation : Data security
2. Polymorphism : One function several uses
3. Inheritance : Write once, use many times
Web has evolved into a global environment ranging from small scale to large scale and enterprise workflow systems. But still the approach towards web application is very ad hoc. It is not in a structured way. Some of the web frameworks support object orientedness, but to a very limited extent. In some frameworks, you can achieve Encapsulation by concept of namespaces or Inheritnace by reusing the available procedures. The concept of object orientedness is present in many web application frameworks, but it is not in a fully structured way.
OOPs concept in web applications
Encapsulation: It can be achieved in the form of classes and access specifiers. The functions defined in the class will not be accessible from outside the class unless it is explicitly defined as public. This way we can achieve better security and can be guaranteed that your code is in control of you and also in a structured way. I say structured because all the code related to one particular module is at one place i.e in a Class.
Polymorphism and Inheritance: These two work in align with each other. Assume we have an class called "Validate" which takes care of validations of some text fields. I can reuse the same functionality in my other modules with the concept of inheritance. Once I inherit the Validation class, I will have all the functions and variables available in my sub class and i dont need to write validation again for my module. I can reuse the available functions.
If my module requires more functionalites or changes in existing functionality of the module, then I can overwrite the function in my subclass. This way we can achieve polymorphism.
So on onverall, object oriented concept will defnitely help a lot in web applications and will ease the job of the developer.
Subscribe to:
Comments (Atom)