We practice agile development methods because they work. In the rough and tumble world of custom software development, we need to be able to create software to support a business process that you just invented -- or that you're still inventing. Rapidly evolving product requirements of the internet age demand adaptive and flexible behaviors from development teams. We work to foster real and nearly real-time involvment between our developers and the client.
Standard Industry Practice
Big shops bring in top talent for the sales meeting. After you sign the contract, you never see those people again. Your project is staffed with random developers, who have never worked together before. Some have never worked with the technologies on your project before. Meanwhile, the top talent is off selling the next load of canned tuna: "white salmon: guaranteed not to go pink in the can!"
They make you pay to even think about building software. A mid-sized project may cost a quarter to half a million bucks or so for a months-long study to "gather requirements" and do "detailed design" before a single line of code is written. A project plan is laid out, calling for 18 months to two years of work, at the end of which a product magically emerges.
Frightfully often, the magic doesn't happen. Standard industry practices carried the software development industry to an astounding 80% failure rate in the nineteen eighties. The project success rate is believed to be only a little better now, with something like 25% of software development projects delivering product of value to the business.
Standard Industry Practice clearly isn't good enough. That's why we use Agile practices.
Our lead developers have worked together for over ten years, in different combinations and on different projects. Like many other lean, nimble teams, we've adapted to new technologies, and new paradigms several times. Along the way we noticed a pattern. High quality software which delivers real value to the customer tends to be created by teams that buck the established industry practice. Like other teams, we decided to revolt against long-cycle development.
We've been using our own Agile or "lightweight" development methodology since the early nineties, refining and adapting our management and development practices continually. Our motto was "Do The Right Thing", and pretty often that included throwing somebody's expensive methodology out the window, and working to implement practices that support efficient software development.
When other teams began formalizing and publishing their methodologies (Scrum, Crystal, XP) we adopted terminology from the Agile development movement, to bring our efforts into alignment with the emerging movement. We generally agree with the Agile Manifesto, crafted in the spring of 2001, by the Agile Alliance. It succinctly describes the core values of a nimble, productive development team.
We employ a variety of Agile practices, which together give us the ability to respond quickly to your changing requirements, adding features according to your priorities, even if your priorities can't be predicted months or years in advance. These practices help us build and deliver software that's useful to you, early and often.
You get frequent opportunity for customer review, a transparent view into the development process -- and control over your project. We don't press a pen into your hand and make you swear that you know everything that will happen to your company in the next two years, and that you won't ever change your mind about anything you currently want or need. Instead, we deliver functioning software and new features on a regular and frequent basis. You get direct access to the development team working on your project, including email and phone contact information. You get a private customer area on our web site where all of your project materials are available -- including the latest build of your software.
Different projects have different natural rhythms, but we haven't found a project yet where the natural rhythm looked much like the typical 18 month waterfall project plan. Generally we deliver a proof of concept within three weeks of project start, by which time major components of the system architecture (database, framework, transports, interface platform) are identified and standing up together. After that, some iterations are as short as a day, some are as long as a few weeks, most are about a week.
All projects are instrumented with automated unit tests. These tests execute automatically during the build process, so that defects are detected and corrected as early in the development cycle as possible. We use popular, well-documented, and open source frameworks in support of that effort, including httpUnit, JUnit, and OCUnit. Your software is easier to maintain and enhance over the project lifecycle as a result.
illumineX can help you build iPhone applications for internal enterprise use, or for consumer use.
