A how-to software guide for federal managers

What: "Managing custom software development in government when you’re not a software engineer," a blog post from 18F's Kaitlin Devine.

Why: Custom software development is becoming increasingly aligned with the mission of many government programs.

Yet many program managers lack expertise in custom software development, resulting in products that are less than optimal in their functionality, user-friendliness and advancement of the program's mission.

Devine's primer, tailored for just those managers who don’t have a background in software engineering, points to two implementation strategies to help guide management of IT needs as a product: agile development and creating a user-centered design.

Agile development "really just means continuous and incremental improvement," as Devine defines it.

"Don't try to plot the three-year path of your product in one sitting," she writes. "Instead, focus on steady and demonstrable progress on individual features rather than detailing every possible requirement up front."

But what does that look like in practice?

At a minimum, she writes, agile software development must entail performing frequent demos of working software, regularly dedicating time for the development to reflect on demos and tests and think about how to improve the product, as well as making a clear hierarchy of priorities.

Additionally, managers in charge of software products also need to make sure they're building something for which users have a need and want to use, she stresses.

Collecting feedback for products from "actual users is relatively cheap when compared to the cost of the added software development time you’ll spend on a feature,” Devine writes. “That cost is only compounded when you find out nobody wants the feature or can figure out how to use it."

Common or repeated themes should be included in future design iterations. Devine stresses the importance of testing products before investing too much time or resources into them, only to later find them not to be useful.

"If it's just confusing your users, it's doing more harm than doing nothing at all," she writes.

Verbatim: "You might think to yourself, 'My job is policy, not software. I can outsource this technology stuff.' Or, 'I don’t need to spend a lot of time and attention on developing a great software product to enable my mission.' Every failed project I've seen has started with such attitudes. Focusing your attention on building a great product lets the software get out of the way of your team's work….Leadership and management for [the alignment between program and policy work and program-specific software] cannot be outsourced."

Click here to read the full post.