Blog

Product or Project Focused

October 24, 2015

A software development team in an organization should be able to focus on the core domain that reflects the business it’s serving. Developers on the team should be able to iterate and further refine the domain model based on the evolving input and feedback of the domain experts. The business people, domain experts and developers treat the software as a product, further evolving throughout a long period of time so far as it provides real value.

Sounds like an ideal world. As we all experienced during our careers, reality is almost never that shiny. Lots of businesses don’t see their software as a product. Instead they pride themselves as “project” organizations, always ready to sacrifice long-term thinking and quality for impossible deadlines. The result is usually a code-base with a lot of technical debt spread with project specific features. This is what we developers call the Big Ball of Mud.

What I just described here are two complete opposites. There are lots of businesses that have a product mindset, and there are lots that have a project mindset. But most organizations sit somewhere in between. In these organizations there is some kind of balance.

A while ago, fellow Elegant Coder David Starr wrote one of the best articles I’ve read in quite some time which is related to this topic. I urge you to read this excellent writing at least a couple of times.

As per the agile manifesto, the only real measure of success is working software. Success on a development team should never be measured in volume of tickets serviced. That sort of measure is appropriate for an operational support team.

In a project organization, development teams are commonly treated as an operational support team, usually not given the right amount of time to focus on the core domain of the business.

If your team is spending less than 75% of its time doing this, you may be on the verge of “going operational” which ultimately means even less time available for new capability development. “Going operational” often represents defeat for a development team.

As with all things in life, there should be a nice balance between product and project thinking with a majority of the focus on long-term development of the core domain model. But then again, there are things that science knows, and then there are things that companies do.

If you and your team want to learn more about how to write maintainable unit tests and get the most out of TDD practices, make sure to have look at our trainings and workshops or check out the books section. Feel free to reach out at infonull@nullprincipal-itnull.be.

Profile picture of Jan Van Ryswyck

Jan Van Ryswyck

Thank you for visiting my blog. I’m a professional software developer since Y2K. A blogger since Y2K+5. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Past organizer of the European Virtual ALT.NET meetings. Thinking and learning about all kinds of technologies since forever.

Comments

Latest articles

Tags

Disclaimer

The opinions expressed on this blog are my own personal opinions. These do NOT represent anyone else’s view on the world in any way whatsoever.

About

Thank you for visiting my website. I’m a professional software developer since Y2K. A blogger since Y2K+5. Author of Writing Maintainable Unit Tests. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Thinking and learning about all kinds of technologies since forever.

Latest articles

Contact information

(+32) 496 38 00 82

infonull@nullprincipal-itnull.be

principal-it.eu
principal-it.be
janvanryswyck.com