RockeTier Agile Development Methodology

Hi,

We at RockeTier, believe that almost any software system can do better by changing and modifying only a small portion of existing code base.
We proved in several cases that using this methodology you can gain major business value in short time. or in other words Agile.

Therefore, it was only a matter of time before we migrate our development team to Agile methodology (you guess right, our software team develops high load software systems which process hundreds of millions of events per day for our clients). This change enabled us providing business value in shorter time frames.

Our development methodology is based on the following basics:

1. System wide design - the product owner is responsible to provide long term road map for the system, including software architecture, database architecture, middleware, non functional requirements, timeline and so on based on inputs from the client or internal product manager. This is an important component which sometimes Agile evalgelists tends to neglect.

2. Product backlog - product owner is responsible for breaking the long term architecture into business processes. Each business process is analysed, confirmed by the client and used as an input for the sprint backlog. Many times business processes are not complete, but describing current days needs in order to gain business value, knowing that these requirements will be changed in the future.

3. Sprint backlog - each business process is broken into a list of tasks (usually by the programmer). This list is documented in a central repository and being written on the team whiteboard.

4. Daily Cycle Status Review- each day a peer meeting is being handled on 10AM, syncronizing open issues with closed issued, adding high priority tasks (usually bugs)

5. Daily Version - each day on 4PM we upload a new "for review" version which includes all the commited new features added to the software in the last 24 hours.

6. Weekly Version - based on the last week "for review" versions we upload a new version on Wednesday 12:00, enabling our team and the client examine the system before weekend.

7. Quality - We believe that people achieve best results when they are responsible for their products. Therefore, most QA is done by the programmers themselves and the team leader:
- Peer review and pair programming - we often use these methods when developing sensitive components and when time is short, to achieve best quality in short time, and in order to reduce the risks.
- Code review - done by the team leader before a new feature is committed to the SVN
- Code management - we use SVN as company standard, but also consider to use GIT, in order commit (locally on your computer) every change you make that way you can return to any point in time but do not break everybody's code if your changes are not complete. and only when code is ready, commit your changes in svn.
- TDD - we use test driven development to make sure that code is not broken between cycles, and making sure that new changes will not harm current business processes

8. Knowledge management - knowing that sharing a knowledge will help our people gain best results, we opened few weeks ago a new code snippets and best methodologies blog. This is an open blog by nature so the community can enjoy our insights and experience.

We seen a great improvment in our development products since implementing this method including: reducing the needed time to get new people into productivity, reducing error and misunderstandings, reducing time to market and reducing bugs,

Keep agile,
Moshe, RockeTier. The performance experts.

How to minimize testing costs using cloud computing

Hi All,

Development of high quality software requires testing. A lot of testings. Usually it requires verifying the new software version on a large number of operating systems. Moreover, if your software system had miles on the road, you usually need to support several previous versions of the software system.

How do handle this large number of servers each required to handle each version, test scenario and operating system? If you are using test driven development it probably even harder... You should every time get back to the base version...

Few years ago, the only option to support such a case scenario was having a large server farm, where servers are restored from backup in the end of each test. The bottom line: this old fashion solution required significant equity and a lot of manual work to perform.

Virtualization changed the market. On a single physical server you can load several logical machines and perform tests. Moreover, if don't need to verify some of the tested versions, you can avoid turning on these logical machines. You thought it could not get better? since virtualization platforms enable getting back to defined points in time, a.k.a checkpoints, you could restore base version by a simple click! The bottom line: virtualization enables software developers and ISVs cut their costs and manual work and get much more using few machines.

These days you can even get better. Using CLI you can automate this process, raise your logical machines just before starting the build and tests, and restore to the relevant checkpoint automatically. More information can be found in Jani Järvinen's article.

What about doing all these testing and performing all these tests automatically without a single penny NRE? Yes we can! using cloud computing can perform all of these by just paying for the used CPU hours and a neglectable payment for the on going storage. Cloud computing providers such as Amazon EC2, Flexiscale and AppNexus enables you allocate servers on demand, attach to them a snapshot and start running your test in short time. Did you know that in just 10 USD you can perform a one hour test cycle on 30 different machines?

During our development when we need to simulate software systems which handle hundreds of millions of events per day. Since several software engineers work on the same project and sometimes on the same file, we need to make several builds every day, in order to make sure that the end of day version will be stable. we found these methods useful. Hope it help you as well.

Best Regards,
Moshe
RockeTier