Measuring Progress with Programming

Writing is quality over quantity. So is programming.

Programming is like writing: it’s 90% thinking and 10% actual writing. About 5% of writing is actually pounding out sentences or lines of code that remain in the final project. Most writers aren’t paid per word; they’re paid for a final product with a certain topic, style, reading level, and target audience. They’re not farm hands in the field, picking words and dropping them on a page to meet a daily word quota.

Pay per word and you get what you pay for.

A common misconception about both the writing and programming processes are that they’re linear, from A to B. Programming, like writing, starts with a vision. The vision could be a solution to a problem or a creative thing that brings joy. The writer puts down lines to capture the vision first. Everything else is built and planned around the vision, which grows more apparent with time and effort until it becomes a thing in material reality, like a book, with which others can interact.

When an entrepreneur micromanages their development team, they don’t let them focus on the vision. They will get lines of code — if that’s what they demand — but they won’t get a real stick with which to measure progress.

So…how do you measure progress?

A program isn’t like building a brick wall, but a story or a book. Have a set dead line in the form of a workable program, every two weeks. You have the vision, so you create the milestones, the checklist, and the goals. Have regular debriefings with your team and don’t be afraid to ask questions or to test your product.  Any development team worth their salt can do it.

It’s like asking a writer to give you an outline, first draft, chapters, revisions, or a final manuscript for publication: each milestone is a vision being made reality. You should treat your two-week sprint no differently than you would treat a writing milestone. You don’t accept a confusing mess with no discernible start or conclusion when you ask a writer for a draft. You don’t expect to stare at source lines of code when you expect an update on your app either.

There’s nothing wrong with expecting updates that you understand.

You find a team that creates for the measuring stick for you.

If you’re familiar with the Joel Test, ask your potential new development team if they do daily builds. A build is literally building the software. Everyone’s work is combined to see if it all works as a cohesive whole. If there’s a problem, the team finds it, isolates it, removes it, and builds again. These daily builds will lead to the finished product. Your team should have no problem sharing these builds with you until they’re ready to ship the final product. Until ship date, discuss how you’ll be kept abreast of any developments, issues, or milestones met and schedule these before development even begins. Set up a way to view their progress yourself through your own agency, such as seeing the source code on Github.

The best way to enforce quality development is to find a team that develops in sprints. Sprints are short-duration, high-powered sessions where a development team focuses only on creating your app, so you absolutely have a product at the end of the sprint. There’s no time to deviate from the spec and no room for useless code, so there’s no need to feel like you have to monitor them. In two weeks, you have your next iteration of your app.


Leave a reply

Your email address will not be published. Required fields are marked *



We're not around right now. But you can send us an email and we'll get back to you, asap.


©GaltSoft, LLC.

Log in with your credentials

Forgot your details?