Lean Development and Agile et all Part 2

Ok so we discussed parts of Agile and Lean Software development in the last post. In continuation with the same, we will cover the different aspects related to these terms so as to get a better understanding over the next few posts. In this post we will talk about Iterations and Increments, Testing and Test Driven Development.
Often the terms iterations and increments are used interchangeably. However there is a difference in what these terms mean when talking in the agile perspective.
Iteration refers to the process, the actual way in which you develop. Its basically defining a fixed cycle of a development period. Why fixed, well we will go into the details of why the cycle needs to be fixed as we continue discussing. Normally the cycle varies from a week to six weeks. If the cycle is longer, it is recommended to have a shorter cycle to maintain a hierarchy.
Increments refer to the product. How much of the product has been delivered since the last iteration. Now what is the measure for determining how much? Is it the lines of code, number of classes, number of components. These terms are pertinent to a developer. What we instead look at is the consumable/usable functionality that has been added to the product since the last iteration. This functionality has to be complete and usable by the user of the system.
Iteration need to be time-boxed and have a ritual. A few common traps to fall into is well, lets say we have an iteration cycle of 2 weeks. Lets say at the end of the cycle, we are not quiet done. So we say lets say the iteration is complete but continue it till Monday. Now a small thing but unfortunately this is an addiction most teams fall into. Iterations need to be serious. After the end of the iteration cycle, we should have a demo. Lets talk a little as to what went well and what didn't. What functionality is complete and whats missing in part. The intent is to learn from each cycle so that there is improvement over cycles. Everyone needs to know when an iteration is complete by having a demo and some retrospection. The intent of the retrospective is to correct what is not right. There's no point knowing it unless you take corrective action. Also the intent is to be fail fast. We should know where we going wrong fast and not wait till the last. The feel where we are going to be complete for an iteration has to be there.
Increments need to be visible. Its about functionally complete slices, not abstract deliverables or work in progress. We need to work towards a list of prioritized items. There are different ways of prioritizing. Some follow the DSDM(Dynamic Systems Development Method) way, where the categorization is MoSCoW - Must have, Should have, Could have and Wont have. Although you can come up with your own categories. This also applies to projects which have a strong architectural perspective. And most importantly, the increment needs to be tested to be considered complete.
Test Driven Development is often confused with unit testing. Well let me clarify. The intent of TDD is not the Test but the Driven and also the Development. TDD does not intend to check the functionality of your code. Rather, it defines what functionality the code should implement. Tests drive the development. They allow the design to be explored. Tests are meant to check the specification of a unit's behavior. Well the difference in having a specification in a document as opposed to a test is that as a test you have a specification which can be run, which is executable.
I'll try and follow up on the same principles in later posts.
(Followed From Lean Development and Agile et all Part 1)

Lean Development, Agile et all part 1

Agile has been around for some time and there has been acceptability across a wide range of teams. Lets delve a little into what aspects agile offers, some common misconceptions of agile and what a lean development takes care of.
For a long time, there has been a misconception that agile implies rapid. Well does it mean you churn out code and features at a breakneck speed. Well where does that lead. To the well known bug list and failures of projects. Not really. The intent of agile is not on the rapidness as understood by many. Its intent is on sustainable and responsive development. Development where there are feedback loops at all levels, customer goals, test results, team feedbacks. The intent is to have tangible deliverables at short intervals of time and a review process to evolve it. Agile development is a lot like a tracer bullet. Every iteration shows how far you are from the perceived goal and refine until you strike the target. Its about the planning and not the plan.
Lean Software Development encompasses a set of principles which lay a structure for lean development. These can be classified as
1) Eliminate waste - As an example, think of the common scenario where you have to people working together. Lets say a Business Analyst and a Software developer. Now in the common scenario, these two would be interacting with each other using some media as paper. They would transmit the document, approve/suggest and re-transmit. Now as humans we are not fond of reading. Some of the most known guru's of software engineering have written some wonderful books. But the most time these guys spend is traveling the world telling people what they have written in these books. The paper ways are a huge waste of time, at the point they are initially exchanged and subsequently when they are debated on. The best way would be to put these guys together and discuss. Then whatever they come out as a document is an agreement and not a work of art on a specified format.
2) Amplify learning - Walking on water and developing software to a specification are both simple processes, provided both are frozen .This was a comment made by a great man long time ago. Its funny and cute but its a bit wrong. Even if the specifications don't change or the technology doesn't change, one thing thats bound to change is you as a developer. Thats because you learn as you build software. Use this learning to improve is what amplifying learning is all about.
3) Decide as Late as possible but at the same time decide as fast as possible-Sounds contradictory but true. When are we most ignorant about the software we are building, at the start. Can guess work reduce your risks. Most definately not. Hence decisions should be made when you have sufficient knowledge. But no later than that.
4) Empower the team - Well simply put, if you dont trust your developers, dont hire them.
5) Build integrity - We are here to build software that lasts. Dont take shortcuts. Dont avoid the good practices for the behest of speed. A lot of products have a core part. A part which few people know and want to work on. Working on that core is a job noone wants to do. The reason, well lets assume you start with a speed x of working. Now due to some factors, you are falling behind. Lets say you avoid writing the unit tests, and dont follow some of the code guidelines. Ok so you got it done in the time allotted. Next time when you work, you are wodking on a bad codebase. Hence your speed decreases and you follow the same workaround. As a result, this process repeated over a period of time will bring your productivty to an almost zero and an unmaintainable codebase.


I will be following this post with later ones that carry on the same idea. Till then ...

Enterprise Information Maps, Impact Analysis, DBC and Eiffel

I got some time again after months to revisit my blog. And i think now is the time when i can put a lot of thoughts and actions here. The last few months has been hectic to say the least, and the future professes to be more. Well i have been working on quiet a few initiatives and a few have started taking shape. My recent energies have been dedicated to quiet a few things , a few which i will discuss here. Over the past few months i have been working on Enterprise Information maps and Change Impact analysis using Information retrieval. In addition there are quiet a few things which i have been looking at. Design by contract was one aspect which i had always been interested in. As a consequence, i studied Eiffel to study how it applies. Been a keen java programmer, i also looked at iContract, a tool which allows adding constructs to java for specifying DBC assertions. iContract is a preprocessor for java, it decorates java files with DBC assertions.
I also revisited shell scripting.
Well moving on to more serious stuff, personal initiatives have revolved around EIS(Enterprise Information Maps) and Change Impact analysis using Information retrieval.

Enterprises today have large amounts of data pertaining to various departments within the organization. However making sense of this plethora of data has been and continues to be a mammoth task. Most measurements are empirical to say the least. Business Intelligence tools go to a small extent to provide some semblance of clarity related to this data. The need of the hour is to provide a way to accumulate data from different sources and provide a tool which provides answers to the basic questions at different levels in the enterprise. My current initiative is to create a product that can answer these basic queries and at the same time shielding the low level technical intricacies from users. Work on this has progressed to a fair extent but it will still take time to carry it to completion.

Impact Analysis Using Information Retrieval

Background : Traditionally impact analysis methods focus on achieving impact analysis using one of the following ways

1) Traceability Analysis

2) Dependency Analysis

3) Judgment based on Experience

4) Code inspection

My approach is to employ existing systems used commonly in projects and employ information retrieval for performing change impact analysis. Currently i am looking at the following 2 systems

1) Bug Tracking

2) Source Code Versioning System

More on this in future posts.
Cheers

Musings high entropy

Well there seems a time when things just dont figure. Whenever i look back on the past few incidents it always seems to remind me of the saying 'Life is what happens when you are planning for other things'. It seems to justify the fact that change and chaos are a very integral part of life and planning just doesnt figure in the scheme of things. There are numerous incidents when i thought i had planned to perfection only to realize that it was a mere misconstrued conception of the mind. Hence the thought arose that there seems to be one way in life ... swim with the tide ... that always helps and you dont end up feeling exhausted. There are differing opinions and people will claim that planning has worked for them but if one sits back and analyzes most of the focal things just happened. Seems there is a fortune, a way life knows and takes you. Anyways time for getting into the normal mundane rigmarole of life so the musings and the entropy has to simmer for the moment... but yeah I"LL BE BACK

A new dawn

It started as a simple idea and now its becoming more and more of a commercial hot watch. The idea was to mitigate some of the drawbacks of traditional software development cycles. When developers can read, modify and redistribute source, it evolves. People can evolve it, fix it and the best part is the speed at which this transition takes place. But its not just about publishing source code. I plan to go into the nitty gritties of open source and will discuss licensing and the other aspects. Any suggestions and criticism are welcome. My endeavour is to create a community in india which starts contributing to the open source world. Its time we moved from being the maintainence and support guys to being the creators. The world is set for a revolution which has taken a long time to become commercial. Lets not miss the band wagon.