TPS is all about finding the most-efficient path to the solution you need. Once we've gained a precise understanding of your problems, objectives, current technology state, related business operations, and other aspects of your case, we create a plan leveraging exactly the right team members, development method, software architecture, and programming paradigm to yield maximum results. TPS allows us to keep costs and schedules from ballooning without sacrificing quality.
T H E R I G H T P E O P L E: H Y B R I D T E A M S
Obviously, we're supremely confident in our abilities. Still, from time-to-time we find that our staff lacks a specific expertise critical to satisfying a project requirement, and that obtaining the necessary skills could result in a delivery delay. In such cases, we don't "fake it 'till we make it" as so many others do: Instead, we enlist a carefully-selected consultant from our expansive network of professional associates to work hand-in-hand with our internal team. In this way, our expertise grows, but not at the client's expense.
This practice is proven, and enables us to deliver a timely, first-rate solution while capping costs to the client. You won't be paying us month-after-month to learn-on-the-job while you wait for an indefinite delivery, and you can trust us to choose a qualified, honest expert — often one we've successfully worked with before — to provide any missing piece of the puzzle.
T H E R I G H T P L A N: D E S I G N E R D E V E L O P M E N T M E T H O D O L O G I E S
Most software houses are committed to a single development process. Perhaps it was the only one presented in detail by the founder's university, or the one used at her first job, or one evangelized by a favorite technology blogger. Whatever the case, it's often true that the only development methodology a software company uses is the one with which its decision-makers are comfortable. In reality, however, it's impossible for a single methodology to fit every project — or even every client. When it doesn't, either cost and schedule overruns emerge or design and/or implementation defects multiply. Either way, the client suffers.
To combat these problems, Blade skillfully employs one of three methodologies:
- Spiral: A design-deliberate process targeting broad-scoped / high-risk / requirement-rigid projects,
- Scrum: An "agile," change-responsive process targeting narrow-scoped / low-risk / requirement-nebulous projects, and
- Rapid Application Development: An iterative prototype process for projects falling between the comparative extremes embodied by Spiral and Scrum.
Depending on specific project nuances — a high-degree of novelty, for example — we might further alter the methodology in order to reduce risk or otherwise improve its fitness to the task. Our ability to identify and work within a development methodology appropriate to each project greatly enhances the prospects of timely, cost-efficient delivery of effective products and services.
T H E R I G H T W A Y: N E V E R O V E R - E N G I N E E R!
Most everyone is familiar with the KISS principle. "Keep it simple stupid" originated in the field of aeronautical engineering, but early software engineers immediately recognized it as equally-applicable to their own work. Although the usage of this adage has has become ubiquitous, it remains a core principal of software development to this day. Reliability, cost, and development time are all inversely related to unnecessary complexity. This is true for both initial creation and continued maintenance. It's as simple as that.
Unfortunately, this enduring truth is often lost when confronted with developer culture. By nature, software engineers want to use the latest technology, even when it's unproven or its scope extends far beyond the task at hand. Object-oriented architectures are constructed without thought as to whether a lighter design would suffice or even surpass. The temptation to write overly-clever code ever-abounds. Software gets gold-plated with features, enhancements, and all manner of bell and whistle. Our heart's desire to create the most advanced and coolest thing possible works directly against the KISS principle we all know we should be following, and it's the client that pays for it in the end.
To combat this phenomenon, we've made KISS the third tenant of TCP in the form of the mantra "Never over-engineer." This means that whether architecting or implementing, we continually ask ourselves how we can simplify the product while still delivering at least the quality promised. As the project progress, this process maximizes value to the client.