I have been in several discussions lately about iterative versus incremental development and there has been a lot of confusion about what each means. I wanted to give my two cents on what I think the differences between the two are.
Incremental development to me is the process of building a whole piece of the solution to its completion and then moving on to the next piece. An analogy that I have used is the building of a house. Using an incremental approach you would build out all of the first floor, including the electrical, plumbing, dry wall, carpeting, etc. before starting anything on the second floor. This way you know that the first floor is complete and ready for the occupants to move in. In software development this would mean completing a subsystem, or a portion of the application, before you start the other subsystems or portions of the application.
Iterative development to me means building a business flow, with the minimum of functionality even, from start to end before adding more features, nice to haves, etc. Using the house analogy you would construct all the framing for a house before you added electrical, plumbing, etc. This way you are sure that all of the framing is solid and the rooms are laid out correctly before you start on the next feature/service.
Incremental and iterative development can co-exist in software development. You could complete one business process with minimal functionality quickly and then start on other business processes. Then you would start working on filling out the functionality of a business process iteratively. This would be incremental and iterative at the same time.
I prefer iterative development because I believe that showing business partners a minimally functioning solution before building out all the functionality gives them the opportunity to change the implementation before it is too costly to make the change. It also means that the business can make a decision that a feature may not be worth the development effort and launch without it.
Monday, February 8, 2010
Tuesday, January 19, 2010
Cloud Computing Buzz
There is a lot of buzz about Cloud computing lately that I think is misleading. Like all new IT silver bullets the advertising machines from vendors have been whipped up to a feverish pitch. They are selling all types of IT snake oil silver solutions and telling CIOs that if they don't have applications in the Cloud soon then they are behind the times and will be replaced soon.
First let me define what I mean by Cloud computing. I define Cloud computing as an externally hosted platform for running applications. This definition has also been known as Platform-as-a-Service or PaaS. Examples include Amazon's EC2 and Google's App Engine. There are many more out there but Amazon and Google are two well known providers. Others have defined Cloud computing as anything that doesn't run in your data center. This would include things like Google Docs, GMail, and the like. I think this is a stretch of the definition of Cloud computing since these are pre-defined applications that have a single purpose. Cloud computing is more general purpose than this definition.
I believe that Cloud computing has a place in the future of some companies. Companies that do not have the cash or people to put a data center together can get huge benefits from cloud computing. The ability to make infrastructure available quickly and inexpensively, initially at least, is exciting. There are several scenarios that companies can use this kind of infrastructure including proof of concept work, development environment, or even self contained applications.
I have an issue with the assumption that Cloud computing is a cure all for all IT problems. The Cloud does not solve the issues of integrating data from legacy systems, which now maybe defined as anything not running in the Cloud, development issues that arise from programming for a new environment, and even requirements issues. These problems will exist no matter where the solution is hosted. There are new issues that exist with hosting an application in the Cloud. Different national privacy laws, getting data out of the Cloud, and service availability are just a few issues that come off the top of my head. These all have far reaching affects on the suitability of Cloud computing for a company.
So if you are looking for a fast and efficient way to get infrastructure up and running then definitively look at cloud computing. But go in with your open. Have experienced IT people ask the hard questions about how the service works and how it will fit into your environment. Look at the cost of not only the infrastructure but the cost of developing and integrating the Cloud environment into your application portfolio.
Just my thoughts.
Tony
First let me define what I mean by Cloud computing. I define Cloud computing as an externally hosted platform for running applications. This definition has also been known as Platform-as-a-Service or PaaS. Examples include Amazon's EC2 and Google's App Engine. There are many more out there but Amazon and Google are two well known providers. Others have defined Cloud computing as anything that doesn't run in your data center. This would include things like Google Docs, GMail, and the like. I think this is a stretch of the definition of Cloud computing since these are pre-defined applications that have a single purpose. Cloud computing is more general purpose than this definition.
I believe that Cloud computing has a place in the future of some companies. Companies that do not have the cash or people to put a data center together can get huge benefits from cloud computing. The ability to make infrastructure available quickly and inexpensively, initially at least, is exciting. There are several scenarios that companies can use this kind of infrastructure including proof of concept work, development environment, or even self contained applications.
I have an issue with the assumption that Cloud computing is a cure all for all IT problems. The Cloud does not solve the issues of integrating data from legacy systems, which now maybe defined as anything not running in the Cloud, development issues that arise from programming for a new environment, and even requirements issues. These problems will exist no matter where the solution is hosted. There are new issues that exist with hosting an application in the Cloud. Different national privacy laws, getting data out of the Cloud, and service availability are just a few issues that come off the top of my head. These all have far reaching affects on the suitability of Cloud computing for a company.
So if you are looking for a fast and efficient way to get infrastructure up and running then definitively look at cloud computing. But go in with your open. Have experienced IT people ask the hard questions about how the service works and how it will fit into your environment. Look at the cost of not only the infrastructure but the cost of developing and integrating the Cloud environment into your application portfolio.
Just my thoughts.
Tony
Thursday, December 17, 2009
Agile Zealots
There are way too many people out in the agile community who claim to be agile experts who will tell you that you are not doing Agile right if you don't do this practice or that practice. They will tell you that if you're not doing Test Driven Development (TDD), paired programming, daily stand ups, etc. that you're not Agile. Who anointed these people and made them the deciders of what is and isn't agile? As far as I've seen the agile manifesto (www.agilemanifesto.org) only states that there are things that agilists find more valuable than others but says nothing about what things make up a true implementation of Agile.
Each group that has decided to go agile has to decide what practices it will start with. I encourage them to start small and build out for a core competency. Start with a daily stand up and small iterations. Maybe use user stories too. But start slowly, gain momentum, and learn as you go. Building from a solid base is better than starting with everything, also known as boiling the ocean, will lead to more confusion and distractions than it's worth. At the company that I learned Agile at we started with a iterations, user stories, backlog, and role definitions. We then went on to do some XP practices after some time. It was still hard to get right but if we'd started with everything we'd have overwhelmed everyone and have gotten less return on our investment.
So if you're new to Agile, don't let anyone tell you you aren't doing Agile right. If you hear that from someone, even one of the leader in the the Agile community, ask them where the definition of what practices you have to do to be Agile is written down. I've never had someone be able to show me where it is. Agile is adaptive and purposely is not defined. You need to define what practices you need for your organization. Some practices may make your implementation of Agile more successful but there's no wrong answer when it comes to what Agile is.
Just my two cents.
Each group that has decided to go agile has to decide what practices it will start with. I encourage them to start small and build out for a core competency. Start with a daily stand up and small iterations. Maybe use user stories too. But start slowly, gain momentum, and learn as you go. Building from a solid base is better than starting with everything, also known as boiling the ocean, will lead to more confusion and distractions than it's worth. At the company that I learned Agile at we started with a iterations, user stories, backlog, and role definitions. We then went on to do some XP practices after some time. It was still hard to get right but if we'd started with everything we'd have overwhelmed everyone and have gotten less return on our investment.
So if you're new to Agile, don't let anyone tell you you aren't doing Agile right. If you hear that from someone, even one of the leader in the the Agile community, ask them where the definition of what practices you have to do to be Agile is written down. I've never had someone be able to show me where it is. Agile is adaptive and purposely is not defined. You need to define what practices you need for your organization. Some practices may make your implementation of Agile more successful but there's no wrong answer when it comes to what Agile is.
Just my two cents.
Subscribe to:
Posts (Atom)
