My organization recently opened up a new green field project and in an effort to avoid some complications we had faced before, I made it an important criteria for the project that the “business” folks should be able to contribute directly to the project whenever it makes sense for them to do so. Basically, they need to learn some CSS, HTML, and basic JavaScript so that a lot of the things they might have otherwise had to somewhat ignorantly communicated to me and other devs about are now their domain. I work for a small startup, so your mileage may vary on these ideas, but I think most of the principles apply in general.
There are two main reasons why this is a good idea: They take a lot of minor fixes off of your plate, and they gain a greater respect for the process which leads to better choices and communication.
Of course, the project has to be designed around the idea that anyone with basic skills can contribute to it. You need to make some important decisions and set things up so that they can contribute. I do not expect them to be hacking on the main application logic, but the simpler website pages of all kinds wind up being a maintenance burden and need to change often, at least in my world. Usually the changes required are simple but the switching costs are large and it is easier if the person who cares most about them just does them. I also think that the best results are achieved when people sink their hands into the clay and do things themselves. A lot is lost in translation under other circumstances.
An alternative in terms of letting business types make little changes is to host parts of your site on software like Squarespace or some alternative. But these tend to be quite leaky abstractions that are limiting in the long run for high-aspiring organizations. You are better off doing it yourself if you want to actually achieve the custom solution you will eventually need.
Encapsulation over modularity
In my experience, the design principle that needs to underscore this strategy is that you should not try too hard to re-use basically any of the code or markup in the parts of your project cordoned off for semi-technical contributors. You are better off focusing on segmenting each thing being worked on so that it does not get tightly coupled to something else. If inexperienced people get their hands on a page, the code is going to get mangled and this is okay. It’s easier to tear down a single page and rebuild it than to have a codebase that is sensitive to every touch. Any notion of “Don’t repeat yourself” should be thrown out the window. Make people repeat themselves. You can evaluate on an ongoing basis whether it is practical to pull elements out as re-usable modules, but do not look to do this prematurely.
Avoid build tools and anything overly fancy
The fewer moving pieces the better in these processes. Do not use Postcss or any other fancy plugin or library. Stick to natively supported basics and technologies for which there are a huge backlog of Stack Overflow responses, because this part of the development will truly be Stack Overflow driven development.
In addition to choosing basic software, make sure to enforce tight constraints about that ensure the aforementioned encapsulation and basically keep things from getting out of hand. Take steps to keep the “global” space from being polluted in any way. Do not encourage messy hacks but be accepting of their inevitability in this system.
Results
Even though you will wind up with some individually mangled pages, if you optimize for encapsulation, you will still end up with a maintainable codebase and a more focused technical team. Business people will be able to fuss over pixels and copy where they care most about it, and because they are just working in the codebase, there is no overhead of a CMS or other system that you will have to maintain. I think you will see that business folks will also develop more appreciation for the process and in turn become more open to your input in the future. All lines of communication will become more open and this will be a major empathy win all around.
Presenting this idea may be the hardest part of the process depending on who you are working with. I certainly know that some of the people I have worked with would be 100 percent unreceptive to this idea. I suggest not being overly pushy about it and introduce them gradually to the concept. Realize that they will in all likelihood be much more comfortable with tools like the Github Desktop as opposed to the command line and you should make every transition as easy as possible. If done right, I think that this process makes for a more healthy and communicative culture.
Top comments (0)