by on

Building software is not an engineering problem, it is a communication problem between engineers and business. Agile Manifesto‘s first and foremost point is about the individuals and interactions. It is imperative that the feedback loop should be as short as possible to reduce the cost of late rework. Each team in an organization would be unique in terms of composition, their communication and means of interaction will be fine tuned for that particular group. The teams should be guided through non negotiable philosophies rather than intricate set of policies, restrictions and tools.

Cliche – ‘Any code can be understood by machines, code should be written such a way that it should be readable by humans’

MatrixCode is read many times more than it is written, so it is everyone’s desire to keep the code base very neat to adhere to good coding standards. One way of ensuring this is to do a code review. With Git the collaboration got easier that you ask anyone to clone your repo, do some work and contribute back through a pull request. Pull request is the only way of contributing code to a project which is otherwise a closed read only repository. The owner reviews the pull requests and decides what goes into his/her repo. The feedback cycle in this manner is too slow but works well for social coding.

Cliche – ‘If you have a hammer then all your problems look like nails’

It is becoming increasingly difficult to gather the right requirements, translate them quickly into working software and that too in an efficient hammer-147840_640manner. It is necessary for us to be able to roll up information from the environment and translate that into the software. To help the evolution we should be able to keep the feedback loop as small as possible so that it is very easy to add the right functionalities at a good pace. I happened to read a nice writeup on the importance of rolling up information from the environment. Many people fail to visualize what their intent is in selecting a tool in the first place, pull requests work very well in controlling what goes into someone’s personal project. It will also be successful in team setups, but it comes with a cost. The cost is the speed of evolution, as it will take longer and longer to sync the commits when the codebase grows.

Cliche – ‘Give a carpenter a latest power drill instead of a hammer, he will use it as a hammer’

penguin-158551_1280In the SOA context it is a double whammy where there are many micro repos and pull requests are used to control the quality of the code. Choice of tools and technologies are always like rock, paper & scissors; what works in one context will not work in the other. Choose the right one considering the intent and moving targets in all dimensions in the system, change the approach if it does not fit in or the situation has changed.

by on

Roadmap A typical roadmap is something which gives a chosen possible path with alternate routes, options and milestones. But these alternatives and options stop at the map level and do not move into product roadmaps in the industries. It is very common to see product roadmaps published with milestones and when to expect them but all of them are linear. It is not a roadmap, it is just the road ahead which is more or less static. Responding to change is possible only when you have a roadmap, else every problem that comes in the way puts us in a hardship as we were not prepared to respond with alternatives.

How do we come up with a roadmap for software projects? Just like maps the requirements have to be visually triaged. We need to collect them at granular level such that it can be captured recorded in one or two sentences that can be written in bold on an index card. These granular requirements are popularly called as stories which represent an action of an end user or the ability of the system.

Once we collect most of the possible actions and abilities then we lay them all together on a large table or put it up on a wall to see them all at one glance. This helps us to triage quickly and discard duplicate ones and add some more if they were found to be missing. Once we have come up with an initial list then we collect the cards as per the priorities and arrange them linearly. If a requirement can be done in parallel then a parallel stream is introduced. In this manner we will be able to have a visual data on what are the dependencies and how much can be done in parallel.

We should play around the sequence and parallel streams to come up with multiple options for milestones and these multiple options together constitute a roadmap. Every few months it is better to revisit to the roadmap as software projects are always a moving target. This is nothing but the release planning meeting mentioned at XP website. We have to be aware of the options and not just rely on the first release plan that we have created, if we rely only on the first draft then it is just the road ahead; we will achieve all the milestones as per the plan but it may mostly lead to a not so desired location.

by on

TestPackage provides a clean way to package your functional tests and run them as a jar file with sharding and package level run options. All that we need to do is created a maven/gradle subproject for functional tests and have the testpackage’s dependency and manifest file entry to get an executable jar package.

Once the jar is created all we need to do is run ‘java -jar the-test-package.jar package.that.contain.tests’. This helps a lot in continuous delivery where the functional test artifact can be created at the build stage and promoted to run at the functional test stage without having to access the source code and rebuild later.