Develop : « enrich, growth a software »
Yes it’s my definition of the word « develop ». I checked the Internet to ensure that I wasn’t wrong and I agree with the correct definition.
Many years ago, on the first 1.0 Magento release, we made a comparison for a request between the commerce server and Magento plateforms. At this time, the clients chose Magento in part because of its functionalities : Yes Magento is rich, and cover many e-merchandiser requirements.
And in case it’s not enough, there is perhaps a module allowing you to customize it according to your specificities. You know it’s quite easily to reach your customer requirement with this solution.
But I’m always despite when I want to use a functionality on my client’s plateform and see it does not work anymore… Why ? How could that happen ? This function was working, and now, it does not exist anymore….
Yes, web developers have broken it, one more time.
Some features that are unfortunately often broken
This is often the same features which are no more unavaible. Here’s a couple of examples:
The stock management
The client manage its stocks in its ecommerce approach and some customization has been made to add new warehouse. Nice. But now, why when I disable stock management on product, stocks are always managed ? Why I can’t disable stock management for a product?
The native search engine when there is a usage of an external search engine
The embedded search engine is quite limited and if you want to take advantage of this solution you can choose to use some external search engines such as Solr or Antidot. But in many cases, their implementation does not respect the native API, and so, you are unable to deactivate it.
The content management in the category pages
Magento allows to display products and / or CMS blocks in each category . Very often a choice has been made to allow Magento to handle client requirement. But why have removed the others case management ? If a client want to change it and customize its sales catalog, why does he have to call his developers and pay for it ?
This list is not exhaustive: tax management, customers groups, the flat catalog, the sales workflow, are others examples of broken functionalities .
The reasons given to break functionalities
When I discuss choices mades with developers, 3 most often answers are provided
Time to develop
This explanation works with your boss or the client, but not with me: I know how long it takes to do work properly, and it’s never more longer.
And how long it will take time to maintain this approach? By experience, each time this is more longer
There is no other way
This one is one of the most frustant answer: I’ve never seen some feature which require to work dirty: this explanation translate often a lack of knowledge of the product.
We can take the example of add a tracker like criteo or xiti in catalog page: many approachs can be envisaged
- You can edit your templates to add the required trackers
- play with layout to customize the page content
In the first case, if you chaange the design applied, you’ll probably need to review your template to append a second time the required tracker. But if you client does not wants anymore use this tracker, it’ll cost many days to remove all these trackers from the page templates
In the second case, tags are not fully integrated to your catalog and do not depend of the applied design. If you wants to disable it, you can do it from back-office or removing from enabled modules
Before developing something, ask yourself how you’ll be able to disable this feature request. It’s a good starting point to view how to implement it without beaking everything.
Note: everything can be rollbacked.
This one makes me often smile: Magento is able to handle more than 1M of products; do you think its more interesting to prevent choose of enrichment made in category is more interesting than fix the SQL queries mades in a loop?
The majority of the platform I’ve seen had a lack of performance sensitization. Before breaking everything, source code should be optimized…
Consequences for the client
These broken functionnalities will always lead to the same results:
A risk for the platform stability
if the developer has made this kind of shortcut, it’s probably because he doesn’t understand how work the enrichment mechanism or the APIs in Magento: there is a lack of knowledge and so, a risk for the client to have more bugs.
Good developers which try to purpose some modules base their module structure on the existing API. If you break them or do not use the expected one, you’ll be unable to use externals APIs. It’ll make TMA more complicate and more longer: render compatible a module in a non standard location can became a nightmare.
Developers, are you happy to do this kind of job? I’m sure not.
Agencies, are you happy to view your developers always locked on a project: it could be more interesting to sell it two times because jobs has been made properly no?
What we could expect
All these problems come from a lack of product knowledge . Two major reasons :
First, Magento is a powerful but complicated product. No documentation is provided and you need to look inside source code to understand how a functionality is implemented, only then can you understand how to customize it. Understanding a software development from source code has always been a worst practice, and it’s always the case for Magento. Hopefully we can expect an better approach for the version 2.0 : Magento heard our complaints and is currently writing a full documentation.
The second problem is the lack of conception in project management : requirements move during definition period, delays are short, scope was not correctly evaluated…all this points lead to the same thing : some shortcuts are made to reduce time to develop. You’ll earn at least some few days but will render the software maintenance more complicated. It may not be a problem if software quality was maintained, but this is never the case.
Finally, the client is locked within a model which perhaps is not the one he was expecting for his business model.
I really hope that with a full documentation, developers will spend more time on their project architecture than on developing