From the customer’s vision to the source code. 10 questions for our plugin developer Andre Peiffer.

broken

How does one translate customer requirements in source code? What are the challenges with this? And is there anything that can throw a WordPress developer? We asked Andre Peiffer, among others at MarketPress responsible for the plugin WooCommerce German Market (WGM).

When it comes to big changes, for example the implementation of the new EU consumer rights in WGM, our customers will have to have a lot of patients from time to time. Why is it so difficult and long-winded to translate actual business cases into programming?

That is mostly due to the complexity that WooCommerce has reached by now. It takes quite some time to check the repercussions of individual changes made in WooCommerce, and to find solutions approaches that will not have a negative impact on other functionalities. After that there are the initial implementation, various test phases, one or more release candidates, more tests, and then finally the actual release. We would otherwise not be able to handle the process, both in terms of resources and complexity, and still guarantee uninterrupted operations for all users and applications.

The work involved was a lot less before the version 2.0 of WooCommerce and WGM, as there were less incompatible processes that had to be aligned. Other adaptations are mostly issues that individual customers have, for example with specific plugin constellations. As a developer, however, I always have to look at the entire picture: Adaptations must never result in unwanted side effects in the code somewhere else. I have to rule out all eventualities, which also involves a lot of work.

And not to forget: unclear or very generalized problem descriptions will result in delays. The customer sees an issue, but has no idea what a resolution will mean for associated plugins or for WooCommerce. In some few, very specific interactions – in particular with third party plugins – a technical solution may simply not be feasible in terms of costs, because entire processes would have to be rewritten, which would endanger the stability or future viability of the entire solution. That’s when you have to try and find a workaround.
 
Can you name an example, where an implementation initially looks easy enough, but which would have widespread repercussions in terms of programming and possible reciprocal effects?

Some users of WooCommerce and WGM have been looking for the function “price per unit” for variable products for some time. It looks like a small feature at first glance, but would in fact mean almost an entirely new product or plugin in terms of technical work, because the solution would entail manipulation of the WooCommerce core processes. And all that against the background of the possibility, that everything else would no longer be functioning properly in a new WooCommerce version. In short: An implementation would not only be costly in terms of the technology involved, it would also be risky. Additionally, it is not entirely clear what this change would mean for the existing functions in WGM. We are, however, still working on a more compatible version, which will solve the problem for some of our customers.
 
WGM is a continuation of WooCommerce. To what extent will that complicate ongoing plugin maintenance? What are the challenges you have to deal with, when WooThemes releases a new version of its eCommerce extension?

WooCommerce is subject to ongoing further development at all times. That means that even long-term internal structures and systems may become obsolete, and that within a very short time. That also has to do with the basic template architecture of WooCommerce. Responding to each and every change soon becomes a very complex project, even if the changes on the user side may only be marginal. It requires a thorough understanding of the depths of a plugin, as WGM interacts with WGM on a deep structural level. All that cannot be accomplished simply via an API (programming interface), and is therefore very time-intensive.
 
Let’s be honest: Don’t you sometimes get a little miffed if a customer complains that things aren’t progressing fast enough, even though you are working on it day and night? How do you handle that type of criticism?

Fortunately, I have support as a buffer between me and the customer. They do a great job. And beyond that: I am fine with it, as long as criticism doesn’t become personal, which – unfortunately – does happen occasionally. Personal criticism is very demotivating, as each and every one of us is doing their best every day. Of course I also understand a customer: he has an issue that needs fixing urgently, or his shop doesn’t work properly – never mind if the cause is our plugin or not. Users simply have no idea about the work involved, and that is why they can become impatient or even angry.

Fact is that pressure doesn’t help, and doesn’t make things go faster. As I explained before, we have to comply with a specific process to guarantee continued operations for our other customers. We publish intermediate releases wherever we can, and even hotfixes for particularly pressing issues in urgent cases. That, however, may not always be feasible from a technical point of view – specifically in cases of dependencies with WooCommerce or third party technologies.
 
How exactly do you communicate with the WooCommerce developers on these matters? Are they actually interested in offering quick and comprehensive support for a relatively small German tool?

There is no official coordination procedure for WooThemes. Communication is usually restricted to pull requests via GitHub, i.e. regular support tickets. On most cases that works well, is very efficient, and pretty quick too – plus it helps other developers as well. For very special cases, I can also contact Woo developers directly via email.

We really don’t get to feel that we are just a small provider, or that our plugin is not actually listed in the WooThemes extensions library. Relations are still friendly, even if there used to be a lot more communication going on back when WooCommerce was not yet as big. After all, we do add general comments to the project, and give feedback for specific features that are relevant for the use cases of our customers.
 
Do you have other developers with whom you can discuss issues like possible solution approaches for WGM and other plugins?

That is quite difficult, because there aren’t many developers outside WooCommerce working on this pretty specialized solution spectrum of WGM. I do read a lot of source code to stay abreast with developments. And I do, of course, communicate a lot with the other developers of the MarketPress- and Inpsyde team.
 
Would you say that the Open Source developer community is becoming more competitive in this respect? After all, everyone needs to look after Number One in terms of business.

I wouldn’t say that. The Open Source developer community has traditionally been very open, and everyone makes a point of supporting each other. The only exception might be if there are several plugins in development concurrently that have kind of the same features and target groups. But that only happens very rarely.

There are also only very few lone wolves in our scene. And any that are there, usually deal with specific content and niche solutions that nobody else is really looking at. We are all on the same side. Everyone contributes code in some shape of form, and everyone knows that it is ultimately about earning money.
 
Here in Germany, eCommerce is currently experiencing a definite upturn, especially in the WordPress environment. New small online shops are popping up everywhere. What do you, as a developer, think of the hype? What new opportunities and challenges do you see?

In terms of WooCommerce, I really think it’s the more, the merrier. More users means there will be more testing and a whole range of new ideas as well. The drawback: Not every one of these new shop operators sees himself as part of the community. The balance between supporters and pure users is shifting – but that really is the case in any successful Open Source project. The side effects – like increased bug reporting – are of benefit to everyone in the community.
 
How do you see the future of WordPress, specifically in connection with WooCommerce and WooCommerce German Market? What are you hoping for, what developments are you looking forward to, and what do you feel is still missing?

Andre Pfeiffer
Andre Pfeiffer
WordPress has long since outgrown the short pants phase, and has grown into a full service CMS. In my opinion it would be a good idea to go back and revise the old code here and there, even if that means saying goodbye to one or two extensions. WooCommerce has similarly undergone some remarkable developments. At first I really thought that there were better systems for operating an online shop than WordPress if I am honest. But I have been proven wrong by the WooCommerce users and their projects.

Plus, a WordPress-based shop has a number of advantages: A great number of users are familiar with the workings of WordPress, which means that they find their way around WooCommerce quickly as well. The future will probably bring more shop alternatives on WordPress basis. WooCommerce’s great success will most likely result in other providers trying their luck in the market. I see that as a positive development, because monopolies are never good for the consumer.

WooCommerce German Market in version 3.0 will come with an entirely new architecture. We hope that it will present a better modularization, and will allow us to respond more flexibly to changes in WooCommerce or individual requirements of our customers. Additionally, it will be a lot more maintenance-friendly and allow new additional features.
 
What do you do to switch off after work and to forget about strings and queries?

I have stopped programming in my free time, although it used to be my hobby – now of course it is my job. If I didn’t, I might lose the enthusiasm I still have for it. From time to time I do some private little projects still, though, and I play (e)guitar. Music helps me to clear my mind.

Many thanks to Andre, who let us have a look behind the (developer) scenes. Do you have any questions about his work with WordPress plugins? You can ask anything you like in the comments section.

Post Sharing

Author Avatar

Editor at MarketPress. Passionate blogger, corporate blog expert and book author (e.g. "Blog Boosting"). Co-organizer of WP Camp Berlin.

Also Interesting

slack-blog

New Plugin: Slack Connector - Connect WordPress, WooCommerce and Slack

by Michael Firnkes

Initially we merely wanted to optimize our own Slack-processes. With automated notifications from our MarkettPress shop, the blog and our forums. The resul ...

Read more
backwpup

BackWPup Pro: Secure WordPress Backup with Google Drive

by Michael Firnkes

The Pro version of our BackWPup plugin supports the backup of WordPress databases and files to Google Drive. But how do you set something like that up? And ...

Read more
multiling

MultilingualPress - Multilingual WordPress for Everyone, Forever Free

by Caspar Hübinger

Our plugin MultilingualPress has been available as a free and a premium version (“PRO”) so far. As of today, both versions are merged into one. Multili ...

Read more
woocommerce-meetups

WooCommerce meetups in Germany, Austria and Switzerland: Community networking

by Michael Firnkes

The free shop system WooCommerce is currently experiencing the same sort of successful development as WordPress itself. It is time to build a German-speaki ...

Read more

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">