Featuritis

Featuritis is a serious disease. It’s not a direct danger to humans, but can threaten business survival and has been known to be contagious to software systems and associated projects. It appears whenever stakeholders of an IT project focus on feature lists entirely, trying to assess project complexity upfront. The pattern usually reads as follows: I am in need of a certain functionality that a certain system is offering out of the box. That’s what will save me a lot of time and money.

Here are a couple of consequences:

1. Narrowing down requirements to a single term may lead to oversimplification. Ticking items off a feature list that coincidentally contains the same terms rarely satisfies the real demands of a business. Often times this leads to unrealistic impressions and causes bad blood between different parties working on the same project.
2. Platform vendors extend their feature list to attract more customers. This results in a high number of features with varying relevance and value for customers. According to the Standish Group about half of the features of software applications are hardly ever used. However, being part of the software, they still have to be maintained and updated. In other words: They have to be paid for even though they are not needed.

Alternatively, project stakeholders could invest some time and define all requirements in detail. Then they would compare them with the actual functionalities offered by a software platform. However, this approach takes a lot of time- and we all know that time is money. I have observed a couple of cases that did combine all requirements of all stakeholders, and took longer than a year. The gathered information was not exactly valuable in any way. In the end, this strategy would end up taking us back to the good old times of the waterfall model, which I guess we can all agree weren’t that good after all. In 2018, the naysayers of agile methodology have become rather silent voices.

In practice, lots of features are no guarantee for valuable project outcomes. I experienced an especially insightful case last week: Even though the Enterprise Edition of a very well-known ecommerce platform brings roundabout 100 modules out of the box, the customer had developed more than 120 project-specific modules over time. Unfortunately, we couldn‘t determine how many official modules were actually used- which had not been possible anyways since the modules were not built to function independent from each other. But one thing became quite obvious: A lot of out-of-the-box features do not reduce the need for differentiation.

Has Spryker become infected with Featuritis?

In some ways, yes. We have to admit that one or two features have to be provided out of the box. Customers simply don‘t want to reinvent the wheel completely. What is needed is to strike a meaningful balance.

So, how does Spryker help me finding peace of mind?

1. Certainly, Spryker offers all features a modern online shop should have out of the box. The complete customer journey starting with landing pages, product categories and product pages, adding items to the cart and check out can be implemented out of the box, while being optimized for desktop, mobile and other devices. Indeed, Spryker doesn‘t end the journey after placing an order: for us order automation is a huge part of the ecommerce deal. You just won‘t see us adding the hundred-and-first off the shelf marketing feature to our core bundles that each and every competitor of your uses as well. We rather like to empower you to develop your special features that are suited as real differentiation to push your business to the next level.
2. To us, code quality is essential. It‘s the limiting factor for development effectiveness of your team developing specific requirements. Everybody knows the impression of massively declining progress velocity during complex projects. In the end, every adaptation, every new feature takes forever, consumes a plethora of money and makes the system a little bit slower.

1. Every software vendor insists their product was developed to an extremely high standard. We can prove it by asking an independent, incorruptible third party specializing in software quality audits, e.g. Scrutinizer. Scoring 9.62 out of 10 points, Spryker outranks approximately 80% of companies. Hence, with Spryker you are faster, during  the set up and ongoing development of your platforms.
2. Performance, scalability or security are not negatively impacted by adding new functions. The Spryker architecture includes the separation of frontend and backend ensures quality of service at any time as long as developers walk the line. Obviously, the aforementioned quality doesn’t hurt as well.
3. Spryker redefines modularity completely: There is no such thing as a default solution in Spryker. There are 200 independent modules doing their bit in the overall system. Unnecessary functions are not even loaded in the code. Neither do they stress the developers nor the system’s performance. They are simply not there.

Does that mean Spryker is my cure for Featuritis?!

For the stated reasons, Spryker can be understood as the agile alternative to existing platforms and rigid feature lists. It was intended to be adaptable to project-specific demands and meet the technical and organizational requirements to do so. Additionally, it allows to experiment with different feature variations to find out what works best for your business. This way you can learn by trial & error and find the best possible feature set for your customers.