Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« Personas for better UX! Is it really necessary? | Main | Standardization - Can it support today's "personalization" needs? »

Feature Engineering vs Sustain Engineering - The debate continues

Feature Engineering [FE] and Sustain Engineering [SE] form the two most important work streams in any large engineering service delivery program.

Feature Engineering [FE] involves design, development, testing and deployment of "new features" in a product. This work stream requires requirements engineering and therefore demands a closer interaction with the business groups and product users.  

On the other hand Sustain Engineering [SE] deals with the task of keeping the "house in order". Ensuring that the existing production systems behave as intended and resolving critical production issues forms the crux of SE. Sustain Engineering requires a thorough understanding of the system and close interaction with the Production Support teams and also Product Users.

So which is important?  - Feature Engineering [FE] or Sustain Engineering [SE]. Without a doubt we all know that the answer is BOTH - but it's not that simple.

I have been a part of both of these work streams as a developer and more recently managing both these disciplines for large programs. As a person responsible for both Feature and Sustain engineering it becomes difficult to manage priorities and affiliations. We have had intense discussions and debates within Infosys about these two disciplines. However, ultimately it's what the customer wants that matters most.

For a Developer or Tester in the program there is always a question about which stream is more important and interesting?  More regarded and respected? And above all which stream is considered "important" by their managers for the recognition of their work and important for "visibility" within the organization.

Managers always have a challenge about the right skill-fitment and resource allocation to these work streams.

• Should a junior engineer who lacks experience be a part of Feature or Sustain?
• Which stream requires more Domain Knowledge and Expertise?
• Which work stream helps in skill development?
• How to keep the all the teams motivated -be it Feature or Sustain?

In a large Agile program there could be multiple Scrum teams that are working on Feature and Sustain and that makes the above questions more challenging.

I have tried to de-construct the "DNA" of a Feature and a Sustain engineer below.

I am a Feature Engineer and therefore,

I am a Sustain Engineer and therefore,


I am responsible for new features in the product that are planned by the business groups for product enhancements.



I am responsible to ensure that the current production system behaves as per design and there are no bugs in the existing system


I depend on Business Requirement Documents (BRD) to know what I need to develop or test



I refer to the Functional Specification (FS) and anything that is expected which is not documented in the FS is classified as a "Change Request"



I need not know much about the whole application as I am responsible for only a  particular feature


I should have a good idea of the breadth of the application for me to succeed as Bugs can be anywhere in the application.



Even though I am fresh out of school I can be a part of feature engineering.



I need to have prior experience to be a part of sustain engineering



My work is more important than Sustain because I am working on "New Features", not mere maintenance of the existing system



My work is more important than Feature because I am keeping the Lights-On. If something goes wrong in the production system all hell breaks loose.


 The debate, however, is a never ending one...


Good analysis Kartik. Bothe FE & SE are always required and the choice depends on the customer. What we as a service provider can do is, to make sure that the current system stays "on" properly and that our intuitive ideas are actually engineered into new features which the customer can use. This way we can expand our current business platter while making sure the customer stays satisfied :)

Kartik, you have started and analize very impportant topic and debate continues but having worked on both side in the past I can say it is not that mutually exclusive too. FE drives SE and SE makes FE usable. Time and relevence is the key here. Especially if you are starting from zero and trying to create new product, FE become challenging and SE may be a way of implementation in the begining. Continuous recovery of SE that can be addressed as parallel descipline helps bring value expected of the product.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.