about brilliant fantastic

Our Process

We sell iterations. An iteration can be one week or two. It can't be longer but it can vary throughout the project based on the high level features that need to be accomplished.

During the iteration, we complete a unit of work that is deployable within a production environment.

This is what an iteration is made up of.

It starts with a chat.

We sit down with your stakeholders. These are the people that have some say in the direction of the product we are building or are affected by the outcome of the product's actions.

During this sit down, we come up with high level 'topics' in what we want to concentrate on during the iteration. We then develop user stories that support the high level topic. We won't discuss items that are out of scope.

Create user stories & features.

Once we get back from our chat, we sit down with the team and further develop user stories as well as start to create features. These features describe, on a high level, what we plan to deliver during that iteration.

These features are not simply text documents. They are executable code. They are not a collection of wasted Word documents but instead a starting point for top down development. In other words, they are useful for developers as well as customers.

Once these are developed, we pass them back to the stakeholders for review and get started with mocking up the features.

Mock it up.

It's hard to get feedback on text. Whether it be user stories or a large Word document. The product, the thing that customers will ultimately use, is the key on getting feedback from customers. We prefer to talk about things that are real. An application on the screen is easier to talk about. It is real. Documents are subjective.

At this stage, we start to mock up the application. We may start with paper and pen to get an overall feel. Once we get an overall feel, we start to mock the application in HTML. We don't wire up the database nor the business logic. This step needs to be able to be thrown out if it doesn't work. It also needs to be used if we are on the right track. This is why we use HTML.

Once we have a good mockup, we take it back to the customer to get feedback. This is the most organized feedback of the iteration. We take the feedback and modify the features we created if necessary.

Get organized.

We are now at a point where we know what needs to be done at a high level. We need to break down the work to lower levels so that we can determine what will fit into the current iteration.

We break down the features into lower level tasks. We determine an estimate for each so we can get back to the customer on what we feel we can put into this iteration and what resources will be needed. We break out the work to individuals and we get started.

Code & communicate.

We now have a lot of lower level tasks that are assigned to us. These are usually staring with the higher level features and drilling down further. We use pair programming when we feel it is necessary and we always use Test Driven Development techniques to drive out the functionality.

We are heads down during these few days but we do not have tunnel vision. We are still in constant communication with the customer.

Campfire ™ is the communication channel of choice. We throw questions, screenshots, and jokes into the room and our customers answer them at their leasure. They use it for questions to us. It's great and things are not lost in email chains.

Show & tell.

At the end of the iteration, we deploy to the staging servers and we meet back up with the stakeholders. We demostrate the work that was completed during the iteration. We collect questions and clear up any issues during the demonstration.

We love this step. Deploying great applications to happy customers is what we live for.

Rinse & repeat.

At the end of the iteration, we determine what worked and what didn't. We address any open issues that we have or the customer has. It's easy. We do more of what works and less of what doesn't.

At the end of the show and tell, we determine priorities for the next iteration and repeat the process above.

People that make this tick

Jamie Wright

Jamie runs Brilliant Fantastic and writes code every spare moment he has. He has over ten years of software development experience in Microsoft technologies and three years development experience in Ruby and Ruby on Rails.

He specializes in application architecture, design patterns, object-oriented design, and test driven development.

He lives in Toledo, OH with his wife, two children, and his dog who poops and pees everywhere but outside (The dog, not the children). He is currently seeking help for his gadget addiction.

Keith Thompson

Keith is a software fabricator extraordinaire for Brilliant Fantastic. He is very passionate about software and constantly seeking better ways to build and mold it.

He has a love for Python and other dynamic languages including Javascript and Ruby.

Keith is currently seeking a Computer Science degree from the University of Toledo but probably getting a better education building real world applications.

A little bit about who we are.

Who we are and how we do it.