UnitedLife 05

Avoiding Scope Creep

Bez názvu – 5

Stephen Baldwin
CTO Livepage, Inc.
New York, USA

Software frameworks are becoming more and more common. You’ll be hard pressed to find a product not built upon a framework, and for good reason. Frameworks allow for rapid development and product completion in months instead of years by eliminating the need to write code for commonly used functions.

Usually a framework will change slowly overtime, allowing products that were built in older versions of the framework to transition to new features seamlessly. Fortunately and unfortunately, in today’s world technology is constantly changing; theories evolve, best-practices are revised and concepts are disproven daily. With these changes, the languages and frameworks used to develop technology – whether it be desktop software, a website or a web-based application – must follow suit in order to continue assisting developers in the creation of modern day technology that meets current standards. This makes frameworks susceptible to getting dated quickly. The way you respond to this evolution may make or break your company (or division of your company).

Take this scenario: A framework your product was built in released a new version that isn’t backwards compatible, or upgrading from a previous release requires manual intervention. This new release may or may not have functionality that would be immediately beneficial to you and your product. Regardless, failure to have your codebase updated to the newer release will lock you into your current version, making all new features released in the future unobtainable; this can sometimes result in being forced to introduce new, less than optimal code known as ‘tech debt’. On the other hand, upgrading will require significant company resources: developer time that you do not have available. What do you do?

This is very common, especially when maintaining a long-running codebase or purchasing codebases from external companies. There is no clear cut answer to this problem, but too often the decision to invest resource is automatically handed down to the research and development team (R&D) without proper influence from the business team. R&D, by definition, has different priorities than the business team. For example, new languages and frameworks will usually appease and interest developers, influencing their decision to invest resource. Development may be faster and cleaner in the new version or in an alternative framework that R&D has proposed, but it is crucial that you envision your product’s future before setting out on approving the budget for a framework upgrade or product rewrite.

Consider asking yourself the following before moving forward: Is now the right time? Are customers expecting a feature in the near future that could be done in your current framework with just a little more effort? How much headache will the proposed upgrade or rewrite eliminate in daily tasks? Is this software product going to be receiving constant new feature development, or just maintenance? These questions will help you assess as to whether it is necessary to upgrade versions and address tech debt now, later, or at all. In short, the decision to invest company resource and developer time needs to be one made from a financial perspective. Schedule weekly meetings with your developers (or if you are the founder and developer, block out some time for assessment) and keep that meeting no matter what. These weekly state-of-theproduct meetings combined with allocating time for your developers to conduct research will keep everyone informed and help you make the decision of what tech debt to address and when.



    UnitedLife 09 (S/S 2016)

Robotic farmers

8. May 2017

    UnitedLife 08 (A/W 2016)

Everything about moles

16. November 2016