Sundarrajk's Weblog

Archive for the ‘Agile’ Category

Why Agile is not successful in Asia?

Posted by: on: June 27, 2016

In ​​this​ very thoughtful article the author illustrates why agile way of working has not been very successful in Asia. It is a sad reflection on the state of affairs. While the author has not taught in India and has not quoted this to be an explicit problem it is should not be difficult for us to extend the same reasoning for India.
​The top reasons that the writer quotes are
​1. Hierarchy rules roost in Asia. As a corollary one does not defy one’s superior in the hierarchy. This leads to the expectation “People expect to be told what to do and people want to tell other people what to do because that is how the system works”. This is apparent. Many projects where the client controls every design and tells us how to code we are OK, but the moment the client says go ahead and give me an application that does this work for me, we are lost as the babes in the wood. This is one of the key reasons many of the projects that we carry out for our Indian clients fail to succeed and if they do so it is only after a lot of struggle and bitterness between the various stakeholders. This is one of the reasons that none of the big IT companies in India have any significant product.
​2. Let’s keep things in harmony. Not only are we not open to saying no or suggesting a different way of doing things to our superior, we do not even voice our opinion amongst our peers especially the loud mouthed ones and the ones who are favoured by the superior. This attitude is partly due to our fear of losing our jobs. We do not have the confidence that if we do fit into an organization where we can speak our minds let us look elsewhere. Traditionally too we are brought up to avoid conflicts. The typical reaction of a parent is “Oh! OK that boy bullies you, stay away from him”. Also our managers do not wish to hear of any problems, they want to have solutions and further the solution should be executed by the one who has suggested it not matter that it happens to be the duty of somebody else to do it.
​3. The third reason is a damnation of our educational system “Asian education system is all about high grades and ranks, not about experimenting, self-discovery and making mistakes, which is what Agility is all about.” How very true. We kill creativity right from the nursery. See the wonderful TED ​talk by Ken Robinson where he criticises the American education system for killing creativity, I shudder to think what he will have to say of our educational system. No rote learning is going to help us become good programmers. We may get all the certifications (and hence my disbelief in any certification) that is required to prove our credentials as programmers (Oracle Certification, Java Certification etc.), as managers (PMP, Prince etc), as architects (TOGAF etc) as IT process organizers (ITIL, Agile, Scrum etc) but none matter as most of us have only learnt the theory by rote and have nary an experience and are absolutely zilch when coming to practising the principles laid out in them.
​4. The fourth reason is the clichéd last straw on the camel’s back. It says “outsourcing” is one of the reasons. The work is outsourced to reduce cost. As one pays less and less one gets lesser and lesser experienced, lesser and lesser quality people to work. Again this is out in open for everybody in the IT industry to see, only we do not acknowledge it. This is another reason why we can almost never develop a product of our own. Chetan Bhagat was not wrong when he stated that we are preparing a generation of not so intelligent people by pushing many towards the call centers.

Ship It! by Jared Richardson and William Gwaltney Jr. – Book Excerpts

Posted by: on: December 11, 2015

tldr; warning

Tools and Infrastructure

Manage Assets

How Do I Get Started?

If you’re not using any type of source code control for your project, make it your top priority.
According to a recent survey, some 40 percent of IT shops in the United States do not use any source code or version control product at all, so we know you’re out there.
  1. Evaluate a few SCM systems. We heartily recommend CVS or Subversion. Both are free and used by some of the largest software companies in the world. If you choose a commercial solution, these products will still give you a baseline to compare their feature sets against.
  2. Learn how to use your SCM.
  3. Generate a single-page quick-start guide that shows how to use the system for common operations.4. Show the system to your team. Be sure everyone is comfortable with the system.
  4. Import your code and supporting files.
  5. Start keeping all your files in the SCM.

Am I Doing This Right?

First, are you actively using the system? If you go weeks—even days—between code check-ins, you aren’t using the system actively. This defeats the whole purpose (backing up your work and maintaining an accurate fine-grained history). Even if your code isn’t ready for the production tree, it can be placed in a private or personal area of the system.
If the hard drive on your workstation crashed right now, how much work would you lose? If it’s more than a day or two, consider changing the way you work.
Also, how long would it take you to get a new machine up and running for development? Are all of your build scripts and development resources checked in?
Can you perform SCM operations quickly? If it takes you twenty minutes to check out code and another fifteen minutes to put changes back in, you won’t do check-ins frequently. Your basic interactions must be fast.
Operations such as fetching differences can put a heavy load on the CPU and disk drives. Quite often companies will put their SCM software on an antiquated computer, making all interactions painful.
Hardware is cheap, but developer time is expensive. Whatever it takes (training, hardware, or new SCM software), be sure that your SCM is fast enough to keep up with you.
Are you backing up the SCM’s repository? If the building burns down tonight, do you have an off-site backup that you can use to restore to another machine? A great SCM does you no good if the data it’s storing gets lost. Be sure you are getting a complete, weekly off-site backup at a minimum.
Finally, do you know your system well enough to perform these basic operations easily? Here’s a minimal list of operations that you need to know:
  • Check out the entire project.
  • Look at the differences between your edits and the latest code in the SCM.
  • View the history for a specific file—who changed this file and when did they do it?
  • Update your local copy with other developers’ changes.
  • Push (or commit) your changes to the SCM.
  • Remove (or back out) the last changes you pushed into the SCM.
  • Retrieve a copy of the code tree as it existed last Tuesday.

Warning Signs

  • No activity in the repository. An unused repository is a useless repository. You should see activity every hour through the day as individual developers check in and check out regularly.
  • Incomplete repository. If the repository contains only some of the files needed to build your product, it’s not pulling its weight. Beware of “experimental” release or test trees that aren’t being stored in the repository or of contents of critical XML files or databases.
  • Slow access. If it takes a long time to check in or check out files, people will eventually stop using it—even if they are using it now.
  • Lost files, corrupted files. Some version control systems (made by certain large, unnamed companies) are known to “eat” files on a regular basis. Upgrade to a real system, such as the freely available CVS or Subversion.

Script your Build

How Do I Get Started?

If you just inherited a new product without an automated build, you should take these steps immediately to get a build script in place:
  1. Have a team member manually build the system while you take notes.
  2. Define the individual build steps.
  3. Pick a build tool but be prepared to revisit other options if this tool becomes too burdensome.
  4. Incrementally script each step; eliminate manual operations one by one.
  5. Run the script on another workstation. This step will catch any accidental workstation-specific code.
  6. Now have another team member try to use the script without your help.
When you complete these steps, you will have a script that should work for everyone.

Am I Doing This Right?

If you’re using your manual build system properly, you will be able to build your entire product:
  • With one command
  • From your Source Code Management system (SCM)
  • On any team member’s workstation
  • With no external environmental requirements (such as specific network drives). If you have issues with any of these items, have another look at your build process.

Warning Signs

  • Your build contains any manual steps.
  • Your build script has to be modified to run on different machines.
  • Only a few team members know how to edit the build script.

Build Automatically

How Do I Get Started?

You must already have a good build system in place to move to the next level with an automated build system.
  1. Select an automatic build system to use. Do not write your own.
  2. Obtain a “clean” machine to run on.
  3. Install your automatic build system, and configure it for your environment. Document every step of the install.
  4. That’s it! You can set up this type of system fairly easily, and the return on investment (known to management as ROI) usually reaches the break-even point in the first few months. If management doesn’t see the benefit, run the system on your own machine at first. People who have never used a CI system often need a live demonstration to appreciate how powerful the concept is.

Am I Using This Right?

If you’re using an automatic build system (or a CI system), you are far ahead of most software teams. But there are still a few questions you need to ask yourself:
  • Do you have tests in the system? After all, no one cares if it compiles if it doesn’t run.
  • Is anyone paying attention to the system? Are the notifications turned on?
  • Does your build get fixed quickly or stay broken for days?
  • Does your build finish in a reasonable time, or does it take too long to complete?
If you can answer these questions favorably, your team will be able to spend their days adding features instead of tracking down which line of code broke feature X sometime during the last six months!

Warning Signs

  • Your automatic build system breaks frequently.
  • Your team ignores broken builds.
  • The build stops running, and no one notices.

Track Issues

How Do I Get Started?

If you don’t currently have an issue tracking system, don’t wait. Don’t delay your transition until you can transfer every issue ever encountered.
That’s an admirable goal, but don’t wait until you have your manual system clean before using the automated system. Just start using it as soon as you can. Enter the new issues in your new system, and over time it will achieve the critical mass of information that makes it a vital resource. If you have the time to populate the new system, great! But don’t make it a requirement for use.
  1. Pick an issue tracking system (Appendix D, on page 172).
  2. Set up a test system for yourself, and learn how to use it.
  3. Generate a one-page quick-start guide for your internal users.
  4. Start keeping all new issues in this system.
  5. Move pre-existing issues over to the new system as time permits.

Am I Doing This Right?

If you track issues with any sort of a system, you’re doing great. The real question is whether you store enough information in the system and whether anyone uses the system internally. Use these questions to gauge your success:
  • Can you generate a list of the top-priority, unaddressed issues? How about the second-tier issues?
  • Can you generate a list of last week’s fixes?
  • Can your system reference the code that fixed the issue?
  • Do your tech leads use this system to generate to-do lists for development teams?
  • Does your technical support team know how to get information out of the system?
  • Can you system notify “interested parties” so tech support (and others) can see when an issue is fixed

Warning Signs

  • The system isn’t being used.
  • Too many small issues are in the system.
  • Issue-related metrics are used to evaluate team member performance.

Track Features

How Do I Get Started?

Getting started here is pretty much the same as How Do I Get Started? in the Issue Tracking section.

Am I Doing This Right?

You’re in good shape if the following is true:
  • You use this system as a first stop when it’s time to generate the next release’s feature list.
  • You routinely record new product ideas in the system.
  • Many of the submitted features are rejected. Otherwise, you’re culling them before you enter them.
  • You can generate the last product version’s “new feature” list by running a report from this system.
  • Your stakeholders can easily check on feature status, and they get warm fuzzies because it matches their expectations.

Warning Signs

  • No new features are being added.
  • Everything is priority one.
  • Features get added but never implemented.
  • Irrelevant features are being added.

Use a Test Harness

How Do I Get Started?

If your team has no tests at all, you may want to discuss it with your tech lead (or manager). You can add tests to your areas of responsibility to show the benefit, but for maximum benefit the entire team should participate as well.
If your team is already writing tests, find out what they’re using for a framework. Many developers write their own framework—don’t go there! But if anyone in your shop has settled on a standard framework or tool, find out what it is and why they selected it; leverage their experience and expertise.
Once you’ve selected a framework, use the defect-driven strategy to create tests for your code. We strongly suggest you create mock client tests, and that you run all your tests in a CI system. A CI system is the best way to assure the tests are run regularly.
  1. Select a testing tool or toolkit.
  2. Start adding tests to problem areas.
  3. Ensure that your tests are being run in an automatic build system.

Am I Doing This Right?

Your answers to these questions will make it clear if you’re on the right path:
  • Is your test suite effective? Are your tests catching bugs?
  • What are your code coverage14 numbers? Are they increasing over time?
  • Is the product you’re testing stable?
  • Are the tests being run automatically?
  • Do your tests tell you whether they pass or fail? (If you have to manually determine whether they passed or failed, they aren’t automated.)
  • Does everyone in your shop have the ability to add tests? (If not, the framework is probably too complicated.)

Warning Signs

Have another look at your strategy if your tests:
  • Aren’t being run
  • Never catch any problems
  • Take too long to run
  • Require significant effort to maintain

Pragmatic Project Techniques

Use The List

Maintain a prioritized list of things to be done with the estimated time required to address it and its status.

How to Get Started

  1. For an entire day, write down every task as you work on it (this will be your “finished” list).
  2. Organize whatever daily task list you do have into a formal copy of The List.
  3. Ask your tech lead to help you prioritize your work and add rough time estimates.
  4. Start working on the highest-priority item on The List—no cheating! If some crisis forces a lower-priority item higher, record it.
  5. Add all new work to The List.
  6. Move items to your finished list as you complete tasks (this makes surviving status reports and “witch-hunts” much easier). The act of creating The List forces you to organize and prioritize your work. Just as keeping a diary helps you think through and understand what you’ve been doing, The List helps you sort out your current workload but in a fairly high-level, lightweight way.
  7. Review The List every morning. Update it whenever new work pops up. . . especially the last-minute crisis tasks; you’re likely to forget about those when someone asks you what you on earth you did all last week.

You’re Doing It Right If…

  • Is every one of your current tasks on The List?
  • Does The List accurately portray your current task list?
  • Did the tech lead or customer help you to prioritize The List?
  • Is The List publicly available (electronically or otherwise)?
  • Do you use The List to decide what to work on next?
  • Can you update (and publish) The List quickly?

Warning Signs

  • You fail to add tasks to The List because you’re “too busy.”
  • More time is spent updating The List than completing the tasks.
  • It takes weeks for team members to complete individual items on their personal lists (hint: the items are too big).
  • The List is updated less than once a week.
  • Priorities on The List don’t match “real” priorities.
  • The List is a closely held secret, not visible to anyone outside your team.
  • In addition to the team’s list, there are other publicly available versions that differ.

Tech Lead

Have a Tech Lead in the Project. The tech lead has several major areas of responsibility that will vary by company and team composition. The following is a minimal list of a tech lead’s responsibilities:
  • Set direction for team members.
  • Orchestrate your project’s feature list.
  • Prioritize your project’s features.
  • Insulate your team from external distractions.

How to Get Started

If you aspire to be a tech lead, you need to prove you’re ready to handle the additional responsibility. Look over the job requirements, and strive to live up to them. Voluntarily perform as many of the tech lead duties as you can. Don’t wait for the job to fall into your lap; demonstrate that you are trying to earn the position and can handle it well.
Use The List for your personal work but also keep one for your team. Monitor work in progress while keeping an eye on upcoming projects.
Evaluate your team’s process. Locating the weak spots and finding practices or concepts to address problems will give you a new perspective. For example, if your team is having trouble keeping the code compiling, then you should set up a CI system on your desktop to help solve the problem.
Don’t give up if you aren’t promoted to tech lead right away. Continue learning and growing for the next assignment. Not everyone has the temperament for a tech lead role, but working toward it gives you a broader picture of the entire project, which makes you a more productive team member. You become a better developer by thinking about and considering how you’d be a tech lead.
If you’ve just become a tech lead, create a rough road map. Chart where the team currently stands and the direction you want them to go. What problems will you address? What work will you encourage?
Make a list of all known problems. Then survey the team to see if they know about additional problems. When you think you’ve arrived at a real list, decide which items you can address and which you can’t.
Daily meetings are a great way to keep track of your team’s work without smothering them.

You’re Doing It Right If…

As your team’s tech lead, you should be able to answer these questions favorably:
  • Do you know what every member of your team is working on?
  • Can you generate a project status summary in less than five minutes?
  • What are the next five to ten features for your product?
  • Can you readily list the highest-priority defects for your product?
  • What was the most recent problem you cleared up for a team member?
  • Would a team member come to you if they needed an important issue resolved?

Warning Signs

Here are some warning signs that your tech lead is ineffective or overbearing:
  • Lacks big-picture view of every team member’s work direction
  • Causes work to halt when they show up
  • Takes credit for the team’s work
  • Fails to solve problems, or worse, causes problems
  • Inaccurately forecasts work time lines
  • Is unaware of team members’ technical proficiencies and/or what team members want to learn
  • Is oblivious to personality clashes on the team

Coordinate and Communicate Everyday

How to Get Started

If you’ve never had daily meetings before, you’re in for a real treat! Here are a few ideas to get them rolling:
  • Be sure everyone knows the format (which questions you want answered).
  • Everyone must answer the questions. There are no passes, and no exceptions.
  • At first, be lenient on the time restriction. A lot of new information is exchanged in the beginning, so you must allow communication to flow freely.
  • Hold your meetings at the same time and in the same place, every day. Make daily meetings a habit, not a chore to keep track of.
  • Post topics that are discussed during daily meetings on a web page or plog
  • Pick a person to start the meeting, and then move clockwise (or counterclockwise) through the group. Randomly picking one team member after another is more apt to make them feel ambushed.
Stay Focused
Daily meetings can be a valuable tool if everyone stays on-topic. It’s important to be very specific in the meeting, Don’t say you’re “70 percent done.” Instead, say that today you added the login screen, and though it’s not functional yet, it should be tomorrow. Pause for a moment if someone says, for instance, that the login screen is broken, and ask them to describe the problem in more detail (e.g., “It doesn’t communicate with the authentication manager yet”). When a project is new, the tech lead runs this meeting, but eventually the leadership responsibility should rotate throughout the group. Use these daily meetings to grow your leaders in-house.
If a topic starts to take on a life of its own, or the meeting starts turning into a problem-solving session, the leader should quickly take it “offline” by having the involved team members get together privately after the main meeting. There’s no reason the entire team should have to listen to Jim and Sue brainstorm for half an hour on a problem that only they have. They can give everyone a short overview of the solution after they’ve found it.
Several prominent development methodologies insist you limit meeting times by having everyone stand. That works, but if the meeting participants are disciplined about being brief (or if the leader is disciplined about keeping everyone on-topic) standing shouldn’t be necessary. Try it both ways to see what works for your team.

You’re Doing It Right If…

If you are already having daily meetings, that’s great! Here are a few guidelines to be sure you stay on-track:
  • Are the meetings useful? If no one in the group is learning anything, the reports might be too terse. If more details are needed in a particular area, push those topics into a side meeting with a smaller group. However, the two-minute rule is a guideline, not a law. You may find thirty seconds is just fine, or you may need three minutes.
  • Are meetings consistently held the same time and place every day, or do they fluctuate? Having daily meetings at the same time and place makes it easy to remember. Meetings can move occasionally, but avoid mixing things up frequently.
  • If you stopped holding the meetings, would people complain? They should! The team should come to depend on the daily meeting to stay “in the loop.” If the meetings can be dismissed, then they weren’t providing value. The team should rely on the daily meeting as an invaluable resource.

Warning Signs

Daily meetings are a great tool. But like any tool, they can also be harmful if handled improperly. The following are a few warning signs that your daily meetings have drifted off-course:
  • Each team member takes ten minutes or more.
  • One team member consistently takes up as much time as the rest of the team put together.
  • People are heckled in a mean-spirited manner. Joking among team members is good (and to be encouraged), but if your daily meetings turn into sniping sessions, they’re not productive anymore.
  • Deal with the snipers.
  • Your meetings consistently start (or finish) late.
  • The meetings become content-free, with developers making claims such as “I’m still 90 percent done” or just “workin’ on the Frozbot.”
  • Team members ramble or forget to report things they’ve done. Privately ask these team members to write down what they’ve done, so they stay focused during meetings and keep their report concise. They would also do well to have their own copy of The List to help keep them organized.

Review All Code

How to Get Started

Code reviews are great tools! Once you get in the habit, you’ll wonder how you ever wrote decent code without them. Use these tips to get started:
  • Be sure everyone understands the type of code review you have planned. Review frequently on smaller blocks of code. Don’t wait for weeks, accumulating hundreds or thousands of lines of changes. No MAD reviews for your team!
  • Have one of your senior team members sit in on each code review for the first few weeks or months. This is a great way to share knowledge and get the reviews on a solid foundation.
  • Make sure your code reviews are lightweight. It’s better to review too little code than too much. Having two overlapping reviews is better than having one larger one.
  • Introduce a code change notification system (see Practice 14, Send Code Change Notifications,, on the following page) at this time. It’s a great complement to your code reviews, and it helps to remind team members who forget to ask for reviews.
  • Make sure you have management buy-in before requiring all team members to participate.

You’re Doing It Right If…

  • Do code reviews get an automatic approval? This shouldn’t happen unless everyone on the team is perfect.
  • Does every code review have major rewrites?If so, it indicates a problem somewhere: either with the coder, with the reviewer, or with the tech lead (who gave the directions that the coder and reviewer are using).
  • Do code reviews happen frequently? If the time between reviews is measured in weeks, you’re waiting too long.
  • Are you rotating reviewers?
  • Are you learning from the code reviews? If not, start asking more questions during your code reviews.

Warning Signs

  • Code reviews are infrequent.
  • The majority of code reviews are painful.
  • People avoid checking in their code because they don’t want a code review.
  • Team members who have reviewed code can’t explain what it does or why it was written.
  • Junior team members review only other junior member’s code.
  • Similarly, senior team members review only other senior member’s code.
  • A single team member is everyone’s preferred reviewer.

Send Code Notifications

How to Get Started

There are several ways you can introduce code change notifications.
We’ve used both manual and automatic systems. With a manual system, you type emails by hand (pasting in code diffs by hand) and send them to team members. With an automatic system, a program that watches your SCM generates notices and sends emails.
Both are valid approaches, but automatic is always preferable. However, getting an automatic system in place may be difficult in your environment; if that’s the case, use the manual method. Make sure your team knows about the notifications before they start arriving.

You’re Doing It Right If…

Notifications must be regular and trustworthy.
Don’t send out five-meg diffs!

Warning Signs

The only real problem you need to watch for here is dependability. The notifications must be reliable. If your team members don’t believe the mail will be sent after code changes, they won’t come to depend on notifications. This is easier to fix with an automatic system than with a manual one, but in either case, you must take this problem into account.

Tracer Bullet Development

How to Get Started

The best way to get started with TBD is to pick a project and try it out.
Review the concept with your teammates before you get started. We’d suggest you try a smaller project first to get a feel for how TBD works.
  • Define your system objects.
  • Define the interfaces between them.
  • Write the interface stubs.
  • Make the stubs talk with each other.
  • Fill in the stubs with functional code.

You’re Doing It Right If…

  • The entire system is always up and “running.”
  • Team members understand the system objects as well as “their” objects.
  • Team members feel comfortable helping out with other system objects.
  • You can rewrite large portions of your code base and nothing breaks.
Warning Signs
  • Team members argue for hours over the “right way” to design an interface.
  • The end-to-end system never actually runs end to end.
  • Builds are frequently broken because interfaces were changed and the consumers didn’t know.
  • You have only one big honking system object.
  • You have 700 itty-bitty system objects.
  • The team has been working for months and the system still doesn’t have compiling stubs.
  • The team has had compiling stubs for months and no working features are in place.

Ship It! by Jared Ricardson and William Gwaltney Jr.

Posted by: on: December 11, 2015

Ship It!Ship It! by Jared Richardson
My rating: 3 of 5 stars

A collection of lessons learned by various developers in the trenches. The book starts off with a quote of Aristotle “We are what we repeatedly do. Excellence, then, is not an act, but a habit.”. The book strengthens this argument by stating “Extraordinary products are merely side effects of good habits.”. So the first tip of the book is “Choose your habits”. Do not follow something just because it is popular or well known or is practised by others around you.

The author says that there are three aspects that one needs to pay attention to:

  1. Techniques: How the project is developed? I.e. Daily meetings, Code Reviews, Maintaining a To Do List etc.
  2. Infrastructure: Tools used to develop the project. I.e. Version Control, Build Scripts, Running Tests, Continuous Build etc.
  3. Process: The process followed in developing the applications. Propose Objects, Propose Interfaces, Connection Interfaces, Add Functions, Refactor Refine Repeat.

Tools and Infrastructure

The author highlights the need for a proper tool for Source Control Management. The author also issues a warning that the right tool should be chosen. A tool should not be chosen because it is backed by a big ticket organization. Vendors would push for “supertools”, but one needs to exercise discretion when choosing between the tools.

Good Development Practices

  1. Develop in a Sandbox, i.e. changes of one developer should not impact the other until the changes are ready.
  2. Each developer should have a copy of everything they need for development, this includes web server, application server, database server, most importantly source code and anything else.
  3. Once all the changes by the developer are finished they should check it in to the Source Control so that the others can pick up and integrate it with their code and make any changes they need to make to integrate.
  4. The checked in changes should be fine grained.

Tools Required for ensuring Good Development Practices

  1. SCM
  2. Build Scripts
  3. Track Issues

What to keep in SCM?

  1. While it can be debated whether runtimes like Java need to be kept in the SCM, it is important that all the third party libraries (jars, dlls) and configuration templates be available in the SCM. Note that configuration templates need to be available as the contents itself can change from environment to environment.
  2. Anything that is generated as part of the build process (jars, dlls, exes, war) should not be stored in the SCM.

What a Good SCM should offer

  1. Ensure that the usage of SCM is painless to the developers. The interactions with the SCM should be fast enough to ensure that the developers do not hesitate to use it.
  2. A minimal set of activities that should be supported by the SCM are
  • Check out the entire project.
  • Look at the differences between your edits and the latest code in the SCM.
  • View the history for a specific file—who changed this file and when did they do it?
  • Update your local copy with other developers’ changes.
  • Push (or commit) your changes to the SCM.
  • Remove (or back out) the last changes you pushed into the SCM.
  • Retrieve a copy of the code tree as it existed last Tuesday.

Script the Build

Once the required artefacts are checked out from the SCM it should be possible for any developer to run a script and have a working system (sandbox) of her own to work on. For this one needs a Build Script. This should be a completely automated build requiring no manual intervention or steps. This build script should be outside of the IDE so that it can be used irrespective of the IDE being used. The IDE could use the same script for local builds.
Once the one step/command build script is ready, automate the build. Ideally everytime a code is checked in the following should be done.

  1. Checkout the latest code and build
  2. Run a set of smoke tests to ensure that the basic functionality is not broken.
  3. Configure the build system to notify the stakeholders of new code checked, the build and the test results.

This is Continuous Integration

Tracking the Issues

It is important to track the issues that are reported for the application so that they can be tracked and fixed.
At a bare minimum one needs to know the following about an issue:

  • What version of the product has the issue?
  • Which customer encountered the issue?
  • How severe is it?
  • Was the problem reproduced in-house (and by whom, so they can help you if you’re unable to reproduce the problem)?
  • What was the customer’s environment (operating system, database, etc.)?
  • In what version of your product did the issue first occur?
  • In what version of your product was it fixed?
  • Who fixed it?
  • Who verified the fix?

Some more that will help in the long term

  • During what phase of the project was the bug introduced?
  • The root cause of the bug
  • The sources that were changed to fix the problem. If the checkin policy demands that the checkin comment indicate the reason for the fixes, then it should be possible to correlate the checkin with the issue that they fixed or requirement that they addressed.
  • How long did it take to fix the error? (Time to analyze, Fix, Test)

Some warning signs that things are not OK with the issue system

  • The system isn’t being used.
  • Too many small issues have been logged in the system
  • Issue-related metrics are used to evaluate team member performance.

Tracking Features

Just as it is important to track the issues, it is important to track the features that have been planned for the application.
The system used to track issues may also be used to track the features as long as it provides the ability to identify them separately.

Test Harness

Have a good Test Harness which can be used to run automated tests on the system.

  1. Use a standard Test Harness which can generate all the required reports.
  2. Ensure that every team member uses the same tool.
  3. Ensure that the tool can be run from the command line. This will enable driving it from an external script or a tool.
  4. Ensure that the tool is flexible to test multiple types of applications and not specific to a particular type.

Different types of testing needs to be planned for

  1. Unit Testing – Testing small pieces of code. This forces the developers to break up the code into smaller pieces. This makes is easier to maintain and understand, reduces copy paste, ensures that overall functionality is, if at all, minimally impacted by refactoring.
  2. Functional Testing – Testing all the functions of the application.
  3. Performance Testing – Testing the application to ensure that the application is performing within acceptable limits and meets the SLAs.
  4. Load Testing – This is similar to the Performance Testing. The goal of this is to ensure that the application does not collapse under load.
  5. Smoke Testing – This is a light-weight testing which will test the key functionality of the application. This should be included as part of Continuous Integration so that any breakage in key functionality comes to light very quickly.
  6. Integration Testing – This ensures that the integration of the modules within the application and the integration of the application with the external systems is functioning correctly.
  7. Mock Client Testing – This mocks the client requests and ensures that the client get the right response and within the expected time period.

Pragmatic Project Techniques

Some of the good practices to follow when working in projects are as follows:

  1. Maintaining a list of activities to do. This should be visible and accessible to everybody on the project. Even the client should have visibility to the list so that they are check the speed and prioritize the items in the list. Each item should have a target time. The list should reflect the current status and should not be out of date.
  2. Having Tech Leads in the project is important. The Tech lead should guide the team in the selection and utilization of the technology. Tech lead should be responsible to ensure that the deadlines are realistic. The Tech lead should act as the bridge between the developers and the management. It is an important role to be played by a person with the right temperament.
  3. Coordinating and Communicating on daily basis is very important. Meetings need to be setup on a daily basis. These meetings should be short and to the point, with everybody sharing details of what they are doing and what they plan to do. Team should highlight any problem they are facing. The solutions for these problems should not be part of this meeting, but should happen separately.
  4. Code review is a very crucial part of the project and every piece of code should be reviewed. Some good practices of code review are
    1. Review only a small amount of code at any time
    2. A code should not be reviewed by more than two people
    3. Code should be reviewed frequently, possibly several times a day
    4. Consider pair programming as a continuous code review process.

Tracer Bullet Development

Just like it is possible to fire a Tracer Bullet in the night to track the path before aiming the real bullet, it should be possible to predict the path of the project using the process opted for.

Process

Have a process to follow.
The process followed should not claim exclusivity in success of projects. If it does so, then suspect it.
Follow a process that embraces periodic reevaluation and inclusion of whatever practices work well for the projects.

Executing

  • Define the layers that will exist in the application.
  • Define the interfaces between the layers.
  • Let each layer be developed by a separate team, relying on the interface promised by the adjacent layers.
  • Keep it flexible so that the interface can be changed as it is hard to get the interfaces perfect the first time around.
  • First create the large classes like the Database Connection Manager, Log Manager etc required for each layer, then write the fine grained classes.
  • Collaboration between the teams developing the different layers is key to the success. These collaborations will Trace the Path that the project will take.
  • Do not let an architect sitting in an ivory tower dictate the architecture.
  • It is dangerous to have one person driving the whole project. If this person leaves, the project will come to a standstill.
  • Create stubs, or mock the interfaces of the adjacent layers so that it becomes easy to test.
  • Code the tough and key pieces first and test them before addressing the simpler ones. It may take time to show progress, but when the progress happens it will be very quick.

Common Problems and How to fix Them

What to do when legacy code is inherited?

  1. Build it – Learn to build it and script the build.
  2. Automate it – Automate the build.
  3. Test it – Test to understand what the system does and write automated test cases.

Don’t change legacy code unless you can test it.

Some other tips from the chapter

  1. If a code is found unsuitable for automated test, then refactor the code slowly so that it becomes amenable to automated testing.
  2. If a project keeps breaking repeatedly, automated test cases, emulating the user actions will help reduce the incidents.
  3. Ensure that the automated tests are updated with change in code/logic whenever required, otherwise these would become useless.
  4. It is important to have a Continuous Intergration so that the automated tests can be run regularly.
  5. Early checkins (in fact daily or more than once a day) and quick updates by the developers is important so that the integration problems are detected as early as possible.
  6. It is important to communicating with the customers and getting regular feedback.
  7. Best way to show the customer the progress of the project is to show them a working demo of the application.
  8. Introduce a process change when the team is not under pressure. Point out the benefit the stakeholders will have with the new process. Show them the benefit of the process/practice rather than talk and preach about it.

A wonderful Dilbert quote from the book
“I love deadlines. I especially love the swooshing sound they make as they go flying by.” — Scott Adams

Some Excerpts from the book

View all my reviews

Are Processes required for Programming?

Posted by: on: December 11, 2015

When I started programming,
I just talked to the customer,
And coded and everyone was rocking,
Nothing was only bluster.

Then they said we need to do waterfall
Somebody talked to the customer,
Someone else coded leading to downfall,
And the project manager went a fluster.

Now they are saying use Agile,
Everybody talking to the customer,
It is making everything fragile,
And the project manger has lost his luster.

Agile is Dead – Long live GROW(th)

Posted by: on: September 1, 2015

More than a year ago, Dave Thomas, one of the original contributor and signator to the Agile Manifesto stirred an hornets nest when he blogged Agile is Dead, Long Live Agility. It created quite a stir in the “Agile Community” (forgive me Dave for using “Agile” as a noun. There is also a talk on youtube Agile is Dead by Pragmatic Dave Thomas in which he has given reasons for his post.

In essence he says that the problem is that the adjective “agile” has been turned into a noun “Agile” by the industry that has sprung around the Agile Manifesto offering panacea for all the ills that plague the IT industry. He and others who support him state that this industry hijacked the word and converted into a money spinning industry that created fear in the hearts of the IT people. It put a fear saying that projects will fail if you do not follow the “Agile Methodology” and did not follow the “Agile Processes”.

He bemoans the fact that people are following “Agile Processes” without attempting to understand the “Principles” behind the Agile Manifesto. He bemoans the fact that while the agilemanifesto stressed on the need to be “agile” and “adapative” when developing software, it failed to stress that “processes” followed need to be “agile” and “adaptive” as well.

He states that “No rule is Universal” and that “Every Rule needs a Context”. This premise has been ignored by the “Practitioners of Agile” and what they are doing is nothing short of “Cargo Cult“.

He says to succeed do the following:
1. Find out where you are
2. Take a small step towards your goal
3. Adjust your understanding based on what you learned
4. Repeat

He appeals the practitioners to show Courage and not fall prey to the fear mongers. The values of agile manifesto are as valid today as they were when published he requests the practitioners to use them to create practices, learn from the practices and keep refining the practices.
He sums up saying “Agile is not what you do”, “Agility is how you do it”.
Similar thoughts are echoed by another contributor and signator, Andy Hunt in his article An Experiment – The GROWS Method. in the article he In this he suggests the same thing. He says that while “Agile Manifesto” stressed on being Agile and Adaptive with respect to design and development it did not stress being Agile and Adaptive with respect to the process.

He uses the Dreyfus Model of Skill Acquisition to explain why the agile movement failed. The Dreyfus Model proposes that people can be bucketed into the following groups based on their skill level.

1. Novice – Rules-based, just wants to accomplish the immediate goal
2. Advanced Beginner – Needs small, frequent rewards; big picture is confusing
3. Competent – Can develop conceptual models, can troubleshoot
4. Proficient – Driven to seek larger conceptual model, can self-correct
5. Expert – Intuition-based, always seeking better methods

He further states
“Research suggests that most people, at most individual skills, never get beyond the Advanced Beginner level. At the Advanced Beginner stage, you’re comfortable enough to sort of muddle your way through. And for most folks, that’s enough. It kind of looks good on the outside, and you can list it on your resume. But that’s a hollow victory. In terms of software productivity, you might as well be coding in COBOL with a pencil on a yellow legal pad.
But here’s the real catch: the kind of self-reflection and self-correction that an agile approach requires is not possible at the lower skill stages. That is an ability you simply do not have access to until you reach the Proficient stage at a skill, which is an advanced stage that the majority of practitioners will not reach.
Showing folks agile practices and asking them to “reflect and adapt as needed” isn’t enough. In order to succeed at software development in the 21st century, we need to take a much more directive and pro-active approach.”

Given this background it is not surprising that people fell hook, line and sinker for what the “Agile Industry” had to offer. They needed something that they could follow and expect success to follow.

To rectify the situation he suggests the adoption of GROWS method, encapsulated in http://growsmethod.com/. This suggests that changes should be introduced bit by bit. A wholesale change never works. Second people should be given the opportunity to experiment with the change the observe the impact has for them. He cautions what worked for one may not work for the other for various reasons and that should be OK. One thing that needs to be kept in mind is that the experiments should be time-capped so that it is not a long drawn affair yielding no result.

He says it is important not to just know “how to do”, but it is important to know why to do, otherwise like Agile the practices will be aped without the underlying rationale being understood which would defeat the purpose of following the practice. For each practice, you also need to understand:
1. Benefits: what is the motivation behind the practice? What will you hope to get out of it, both long term and short term?
2. Where do you get feedback from? With an empirical approach, feedback is everything. Where is the meaningful feedback, and what is just a distracting (or even dangerous) metric?
3. What does it look like in the real world? What are the warning signs if not done correctly? These are the things an experienced practitioner may know, but are hard to come by otherwise.
4. What can you do to improve your skill at this level? How do you get to the next level?
5. At the higher skill levels, how do you then teach this skill to others?

All in all everybody says that Agile has been exploited by the mercenaries who are in to make a profit on every buzzword and that is what has happened with “Agile” and it is time to rethink.

Although it seems and sounds pragmatic, in another decade we may say GROWS has become stunted and we may have Andy standing up and saying that the verb “grows” has been converted into a noun by the “treasure hunters” in the industry.

P.S. Actually GROWS is already trademarked, I do not know by whom. Maybe by Andy himself?


Categories

Create a free website or blog at WordPress.com.