The Myth of Software Estimation

A few months ago a web service I’d written began to eat up memory like crazy. I’d coded it using a modern garbage controlled language so theoretically a memory leak was impossible. But, it was happening. I tracked down every obvious choice. I talked to my co-workers. No luck. Finally, after two weeks I finally discovered the problem–a small bug inside a loop was interacting with Microsoft Active Directory to create hundreds of AD tokens. Another bug caused these tokens to skip garbage collection. Schedule? Throw that to the wind.

Evidence Based Scheduling

Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.

Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.

Life of a BUG In Bugzilla

Wiki for Agile Development

Here's a summary of ways that wiki can help with agile development. Need to add illustrations of each of the components and reference links. Improvements and additions most welcome Adina

Wiki was invented to help with Extreme Programming, and can be very helpful in various phases of agile development process. For those not familar with the buzzwords, Agile is a family of development methods with shorter, more iterative cycles than traditional "big bang" development.

Wiki can be useful in a range of XP and agile development practices, including:

• Planning game -- co-operative planning of short iterations with the customer
• User stories -- plan development based on stories where the user achieves a goal
• Acceptance Testing -- user define the criteria for a successful feature, and tests are developed based on the user goal
• Standup meeting -- frequent short meetings to check status and troubleshoot
• Metrics for problem-solving -- monitor progress using a small carefully selected set of metrics designed for specific improvement goals

Wiki also helpful in facets of development not tied directly to XP

• Emergent documentation
• Product requirements roadmap

More >>

TDD = Refactoring + TFD.

Creating a Product Backlog

Very good thought about how the product backlog is created and prioritized. Nice diagram that helps a lot in the real world.

Agile modeling

The best practices of AMDD are:

1. Active Stakeholder Participation. Stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques.
2. Architecture Envisioning. At the beginning of an agile project you will need to do some initial, high-level architectural modeling to identify a viable technical strategy for your solution.
3. Document Late. Write documentation as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.
4. Executable Specifications. Specify requirements in the form of executable "customer tests", and your design as executable developer tests, instead of non-executable "static" documentation.
5. Iteration Modeling. At the beginning of each iteration you will do a bit of modeling as part of your iteration planning activities.
6. Just Barely Good Enough (JBGE) artifacts. A model or document needs to be sufficient for the situation at hand and no more.
7. Model a bit Ahead. Sometimes requirements that are nearing the top of your priority stack are fairly complex, motivating you to invest some effort to explore them before they're popped off the top of the work item stack so as to reduce overall risk.
8. Model Storming. Throughout an iteration you will model storm on a just-in-time (JIT) basis for a few minutes to explore the details behind a requirement or to think through a design issue.
9. Multiple Models. Each type of model has it's strengths and weaknesses. An effective developer will need a range of models in their intellectual toolkit enabling them to apply the right model in the most appropriate manner for the situation at hand.
10. Prioritized Requirements. Agile teams implement requirements in priority order, as defined by their stakeholders, so as to provide the greatest return on investment (ROI) possible.
11. Requirements Envisioning. At the beginning of an agile project you will need to invest some time to identify the scope of the project and to create the initial prioritized stack of requirements.
12. Single Source Information. Strive to capture information in one place and one place only.
13. Test-Driven Design (TDD). Write a single test, either at the requirements or design level, and then just enough code to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory approach to testing.

First Day at New Company!!!

This is a wonderful day in my life. I mange to be on time at the office premises. Although many important people are missing today, others made this day quite a bit exiting and encouraging. Met with many people who are bit busy but made me understand how important the work ethics even when the senior members are not present.

I spent most of my time reading company policy manuals. Looking forward to get my hands on to projects in coming weeks.