Using Fitness-Function Driven Development to optimize product modernization efforts
Back to table of contents
Mining 3 sources of untapped value in your legacy products
Next
03
Previous
01
Ignore these common development practices for maximum success
6 minute read
Back to table of contents
Next steps
Re-imagine software products
Leverage our expertise in next-gen MACH software architectures to modernize your software products quickly.
Learn More
Rejuvenate mature products
Focus on improving revenue, efficiency and customer delight with our intelligent sustenance engineering framework.
Learn More
Re-group with our experts
Schedule a discussion with our modernization and sustenance experts who can help you chart a path forward.
Contact Us
Next steps
Re-imagine software products
Leverage our expertise in next-gen MACH software architectures to modernize your software products quickly.
Learn More
Rejuvenate mature products
Focus on improving revenue, efficiency and customer delight with our intelligent sustenance engineering framework.
Learn More
Re-group with our experts
Schedule a discussion with our modernization and sustenance experts who can help you chart a path forward.
Contact Us
Fitness function driven development (FFDD) is a variation on test-driven development that encompasses validation of business outcomes along with testing alignment to architectural goals.
FFDD serves the same purpose as traditional [test driven development], in that it allows for testing to inform development and to provide a continuous feedback flow, but it also has the advantage of collecting input from stakeholders and forcing early discussions regarding trade-offs.
It’s difficult to accumulate years of experience and expertise following one set of development conventions and best practices, then be told to completely abandon that body of knowledge in favor of a new way of doing things. It’s human nature to favor the familiar and routine.
Many developers fond this to be the case when organizations migrated away from the waterfall/iterative development model in favor of agile development practices.
There is one solution that can help any development team avoid a “two steps forward, one step back” journey to product modernization: introduce new frameworks and tools to help “lock in” desired thinking and behavior.
In this case, the fitness-function driven development approach might be the right tool for the product modernization job. As one Persistent developer explains it:
The fitness-function driven development approach ensures the structure of the development teams mirrors that of the resulting microservices architecture: independent, agile, yet tightly orchestrated to deliver business value at speed.
In a typical legacy monolithic development model, development teams would have an enterprise architect responsible for developing the vision and ensuring everyone on the project was executing in line with that vision.
That can’t happen with a microservices-led product modernization effort, since each service is beind developed by its own team. Then who creates the vision and leads this modernization effort? The business and the customer. With FFDD, before any feature is promoted to production it must be validated for operability standards.
This way, as services are being created through coding and scripting, the architecture evolves organically, much like our strangler vine analogy in Strangling the Monolith. Because there’s no need to abide by a single architecture or set of dependencies and shared code, development can take place at a much faster rate.
All the while, FFDD forces decisions to occur earlier, before development resources are committed, while also serving as a constant check during the normal development process.
The fitness-function driven development approach ensures the structure of the development teams mirrors that of the resulting microservices architecture: independent, agile, yet tightly orchestrated to deliver business value at speed.
In a typical legacy monolithic development model, development teams would have an enterprise architect responsible for developing the vision and ensuring everyone on the project was executing in line with that vision.
That can’t happen with a microservices-led product modernization effort, since each service is beind developed by its own team. Then who creates the vision and leads this modernization effort? The business and the customer. With FFDD, before any feature is promoted to production it must be validated for operability standards.
This way, as services are being created through coding and scripting, the architecture evolves organically, much like our strangler vine analogy in Strangling the Monolith. Because there’s no need to abide by a single architecture or set of dependencies and shared code, development can take place at a much faster rate.
All the while, FFDD forces decisions to occur earlier, before development resources are committed, while also serving as a constant check during the normal development process.
