Redforest Enterprises offers a range of technical services. The principal, Larry Colen, has over 20 years of professional experience, mostly in low level software (embedded systems, firmware and operating systems), but his experience includes all aspects of a project including, collecting customer requirements, specification, design, low level programming, user interface programming, test, documentation, hardware bring up, project management, quality process and even a little bit of hardware design and repair.
Redforest Enterprises offers an innovative service which we call "Software Cleanup And Review". In prose, a copy editor will review a document, correct spelling, grammar and punctuation mistakes and will also suggest alternative wording to improve the readibility of the piece being copy edited. Software copy editing combines features of "pretty-printing" to achieve a consistent style, code review, to check for errors and suggest improvements, technical documentation improving the comments within the code and technical writing, creating or polishing documentation about the software.
Early in the life of many startups, when code is written, expediency is often placed at a higher premium than maintainability, and sometimes even design. It is more important to have a product than a product that is optimally efficient, well documented, and maintainable. Without something to ship, or even to demo, there will be no money to make sure that the code meets higher standards than "it pretty much works". Not only is this a pragmatic tradeoff, it is often a smart one. I've already mentioned the primary importance of having some sort of product, but early in its life the software can change tremendously as various chunks of prototypical code are tried, discarded and replaced. The lack of documentation is not much of a problem when the entire software department can fit inside a small room, or even on a single chair.
When a company is small and growing slowly, it has the luxury of being able to only hire the very best people, and they are hired slowly enough that asking questions of the original author is not only practical, but easy. There comes a time, however, when the pace of hiring picks up, and the authors of the code no longer have time to help every new programmer with their questions. As a matter of fact, they may have moved onto management roles, or left the company entirely.
New engineers at companies, at this phase of their development, may be faced with the frustrating task of learning a code base that has inconsistent programming styles, the code is poorly documented, if at all, and many of the comments are incorrect or misleading. If a design document exists outside the original author's head (assuming it exists even there at this point), it is often several revisions out of date.
Each new engineer has to go through the same process of deciphering the structure, and the inner workings of this poorly documented code. If they make notes, they rarely share them with others. The original authors are inevitably too busy to go back and clean up software that they had originally written several years previously.
We provide the documentation, both in the code and external, that makes it easier for a new employee to learn the code base. In addition, during this process, we'll review the software for bugs, and making sure that all of the code is written in a consistent style, with informative, accurate comments.
Do you have any questions? They may be answered in the FAQ.