We code in pairs. Our programmers like it and, from a business perspective, pair programming is effective and efficient.
At Cyrus, we rely on the dynamic of the team for decision making. Everyone has a say and the client gets the best results.
We went to help a client improve their software. We helped them write the tests in Ruby. Then we needed to get more information – what if a change was made that broke the user interface?
We set up another suite of tests, in Selenium, which runs on a continuous integration server. We developed an automated tool that would take a screen shot of the webpage when it failed and package it with a report of what happened on that build. This way you could see both the unit test failure message as well as the corresponding screen shot and server log. We did all the development on Unix machines but it had to run at the customer's site on Windows. And then we extended the tool to work in programs written in Perl and C. A nice challenge.
– Dan
Tech Lead, Cyrus Innovation
In general, we developers have lots of control over the technologies we use. And if we try something and it sucks, we have the freedom to change it. For example, we were tasked with putting an auto populating search bar in an application. We chose an AJAX library for that.
Another example: we started using Ruby on Rails pretty early on, before it was the big thing. Some of us were playing around with it at home, but then we went to Agile 2006 and found out some people were using it professionally. So we tried it, too. And Google Web Toolkit – a few of us read about it on technical blogs, thought it would be a great tool, and started using it. That's how it goes here.
– Michelle
Developer, Cyrus Innovation
We were building an accounting system that needed to track expenses against budgets using figures the client's accountants entered. The system performed complicated calculations and generated management reports. Rather than write the logic in Java code, we expressed it in plain text files. Then we wrote a parser so the program would read the formulas and apply them dynamically.
It was really neat showing the customer the logic as well as the data they needed to acquire. Users also asked for a way to define the equations themselves if the problem changed. So we wrote a Java web application that used AJAX to make on-the-fly calculations and generate desktop warnings when something was invalid.
Later we expanded the app with internal tests executed with an automated tool we built with Selenium that emulates a web browser. If there's a problem, the tool reports it before a bug is introduced into the system.
Very fluid and responsive.
– Dan
Tech Lead, Cyrus Innovation
We were doing a legacy migration. We had a copy of the program, no client developers who had worked on it, no source code, no manual. So our team had to reverse-engineer the old program, and it was up to us how. We ran the application, clicked around, did SQL tracing and from that figured out how the data was stored that we needed to get into our new application.
– Michelle
Developer, Cyrus Innovation