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
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
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
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"
We provide easy-to-read documentation (including
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
the reference, the better.
Read about DCSoft Technology
Discuss your project with DCSoft
March 29, 2010