Our Creed:  DCSoft Methodologies

Demos, Demos, Demos All the time 

From the first milestone, we deliver increasingly functional, usable software.  We decompose the project into demo-able milestones so you can see core features fully working and be confident that they are converging toward a steady and on-time shipment.  Each milestone features a demo that you can actually run yourself, showing the actual code (no mockups) running to achieve major functionality.  The state of the milestone is laid bare, and you can easily gauge the progress for yourself, inspiring confidence.

Deployable from Day 1 

We have established an excellent track record shipping mass deployed Windows applications.  We make sure from Day 1 that your project is easily deployable.  We ask for your Setup and System requirements, then select our language and frameworks based in large part by whether they fit your deployment criteria.  Statically linked ATL and MFC projects have drastically eased many clients' deployment issues.  We stay away from separate redistributables unless absolutely necessary, and we reduce your download and memory footprints to a minimum, if that is a priority. 

We treat the Setup on par with the app.  Setup is very difficult to get right, on all systems.  And equally as important as the Setup is the Uninstall.  Your app needs to uninstall cleanly, with no remnants, and preferably without rebooting.  We also take care of Localization from the start, or else your app will not be easily localizable, and schedules will slip. 

We ask these questions and recommend appropriate technologies before development starts, to avoid hidden slippages from these things that are too often forgotten.  We specialize in highly deployable apps.

Minimum Quality: Beta or better

Early in the project, we focus on identifying and addressing high risk areas as quickly as possible, while sufficient time still remains to find the best solution, especially when several attempts may be needed to successfully mitigate the risk.  At all milestones in the development cycle, we strive for Beta or higher quality.  This means that the features that are implemented have been intelligently unit tested by the developer before check-in, and that the feature essentially works as advertised.  Perhaps not in every corner case, or as smoothly as we would like, but well enough that you will feel confident passing it around your team or to your CEO.

We don't wait until until the last minute to address massive memory leaks or performance issues.  Instead, we keep a sharp lookout in daily builds, and as soon as they appear, we stop working on new features until these core flaws are fixed.

Once the Beta or Release Candidate stage is truly started, the hard work is over.  Of course, software being what it is, it is only now when people actually start using it, and then the inevitable Change Requests roll in.  Since we have already found the needle-in-a-haystack memory leaks and random crashes, we are in a better position to implement these changes... and still ship in time.

Perseverance During the Marathon

Of course every project has rough times when solutions are evasive, or last minute requests force dramatic and major code change at the last minute.  This is where our decades of experience architecting your software using best practices and coolly facing deadlines really pays dividends for you.  We know where to look for solutions, and our bag of tricks, honed over the years, will be brought to bear with full force.

Near Magazine Quality Code

Our code is our craft.  Before writing a single line, we envision what it needs to do, and we write it so it does exactly that, as precisely and concisely as possible.  When one layer will do, we use one layer and not extra.  Well-placed comments make the code easy to comprehend, without unduly distracting from the code itself (which should be the center of attention).

Since we never know how priorities might change, we write the original code as if it were our only attempt to get it right.  We don't leave the refactoring, commenting, unbalanced news/deletes, etc. "for later."  To hasten usability, we may intentionally start with simple algorithms like bubble sort and clearly comment that we should replace it with qsort if performance is inadequate during testing.  But any work we leave "for later" could be classified as Enhancements. 

All this is saying that our code strives to be "near magazine quality," the kind of easy-to-understand code that you might see in a magazine article.  The reason it is not "full magazine quality" is that the effort to deliver the extra polish to actually be in a magazine is not normally a wise use of time or money, especially since the code in question might be replaced as feature sets are refined.  In addition, our real-world code tends to be slightly more cluttered with error checking, which usually does not appear in a magazine.  All in all, we spend slightly longer up front to grace your Version Control System with much more maintainable, reusable, and debugged code at the start.

And once it's checked in, we don't forget it.  We continually refine the code we are actively working on, and don't just patch around unclear or unoptimized code... while respecting code freeze requests if shipment is near.  (We don't unnecessarily put your project at risk to make "gratuitous" code changes.)

Concise Documentation

We provide easy-to-read documentation (including Camtasia video screencasts, which transfers ideas faster than we've ever seen) to ensure everyone is on the same page.   Documenting algorithms and API's is extremely important, and our clients have praised us for great documentation.  But, you can't ship documents!  Working code that you can actually play with gives you far greater insight than storyboards or paper prototypes into refining features and UI.  The sooner the working code becomes the reference, the better.

NEXT:
Read David's Resume
Read about DCSoft Technology
Discuss your project with DCSoft

Last modified: September 10, 2007