In Part 1 of this “book” report, we gave you a rundown of all our white papers related to Agile and Lean software development. Hopefully, you found at least one of them intriguing enough to download and read—perhaps the one about Agile’s CapEx/OpEx advantage?

In this installment, our Really Serious Person sums up the white papers we’ve written about proper software engineering.

Over to you, Really Serious Person…

Proper Software Engineering: An Executive Primer

Who should read it: If you’re wary of choosing the lowest bidder for a software project and you want some criteria for assessing real value, you should read this paper.

What’s in it: We look at what drives businesses to insist on proper software engineering and then we list some consequences of sloppy software development. We explain the difference between engineering and writing software, and we discuss indicators that can tell you if a developer is using proper software engineering practices. We conclude with some tips for choosing the right development firm.

Key takeaways: You’ll have meaningful criteria for evaluating software development firms.

In a nutshell: Why proper software engineering is a must-have.

The Importance of Software Architecture

Who should read it: If you’ve heard that all Agile firms take a fly-by-the-seat-of-your-pants approach to software development, you should read this paper before outsourcing your software project.

What’s in it: We highlight the complexity of software applications and the need for good planning. We describe software architecture, discuss architecture’s guiding principles, list some indicators of proper architecture, and emphasize the importance of keeping architectural options open for as long as possible. We examine the characteristics of a good software architect and, finally, close the paper with a discussion of the challenges to proper architecture.

Key takeaways: You’ll learn the basics of software architecture.

In a nutshell: Why proper architecture is essential.

Test-Driven Development: A Commitment to Quality

Who should read it: Read this paper if you want to learn how a development firm’s approach to quality can have a huge impact on your software project.

What’s in it: We compare the traditional approach to quality assurance with the proactive methodology of test-driven development (TDD). We explain why TDD fits well with Agile and Lean principles and we talk about how TDD works. We conclude by listing some advantages of TDD and some questions that you should ask a software development firm before you sign their contract.

Key takeaways: You’ll understand the basics of test-driven development.

In a nutshell: Why test-driven development is the best approach to software quality.

The Software Reality Check: Diagnosing Software Projects in Crisis

Who should read it: Read this white paper if you want to know how we can help get your troubled software project back on track.

What’s in it: We describe some warning signs of a failing software project and explain why managers are often powerless to halt the decline without external support. We list 10 common problems that can compromise a software project and then explain the benefits of a third-party project audit. We ground the discussion with a short case study before moving on to describe the three main parts of our audit: the architecture review, code review, and team review.

Key takeaways: You’ll learn why software projects commonly fail. You’ll understand the criteria we use to assess troubled projects.

In a nutshell: How we diagnose failing software projects.

Great Team, Great Software: Understanding the “People” Factor

Who should read it: If you’re wondering what distinguishes a great software development firm from a mediocre one, read this white paper.

What’s in it: We explain that software is a unique product built by creative knowledge workers who deserve respect. We look at where the “people” aspect of software development comes into play: management, culture, work environment, teams, career development, and learning. We discuss the consequences of treating people as a commodity and then list the benefits of treating people with respect.

Key takeaways: You’ll learn why development firms that treat people with respect are more likely to build great software.

In a nutshell: People build software for people.

If you’d like to learn more about proper software engineering, please contact us. We’ll be more than happy to tell you about how we build great software for our clients.

Coming soon…the third and final part of our 2010 Architech “Book” Report: White Papers about Custom Software and Marketing Automation.