To code or not to code

Web site owners hate data stuck in code. Web site owners hate calling in a developer to make a minor change. The owners want everything in the administration user interface where they can select, deselect, select, change their mind again, and experiment with everything, preferably with an undo button.

Most web developers working on Drupal, and similar projects, come from a code development background. Those developers prefer to put data in code. Heaps of business decisions are made by developers then locked in code as values in variables or workflow forced by the logic flow. Every point locked in code has the potential to generate a future change with the minimum two hour call out fee, work that is often performs remotely and in under ten minutes.

The battle for control, and contract extensions, continues. While the developers charge for a two hour change, they can complete it in ten minutes because all they do is change the value in code, they do not move the value out to the administration user interface where the web site owner can make the change in the future.

Drupal 8?

Drupal 8 will not change anything. Drupal 8 is just changing the mechanism behind the existing user interface.

Drupal 8 will expand the testing of code and will provide better mechanisms for user interface communication but does not impose standards for the design of the administrative user interface.

Frameworks?

Frameworks make the situation worse. Frameworks let the developer develop more custom code. Frameworks let developers download unknown code from the Web and plug it together in ways that prevent any other developer working on the same system.

Frameworks can save time because they let you use code developed by other people. Frameworks also let you use code that is not designed for the system you are developing. Framework code might save you time or it might be a big distraction while you develop a mass of code to connect almost compatible code modules.

What is really needed is a common testing system for modules with a common use. Drupal performs some testing on Drupal 7 core modules and is proposing a minimum testing standard for Drupal 8 contributed modules. What is not yet mentioned is a way to find out if two contributed modules are tested together on the same site.

Webform?

Webform to the rescue. Yes, the optional add-on Webform module. There is a way to use Webform to move some business details out of code into the user interface.

Webform is one of several tools to make development easier. Some of the other modules are 80% or 90% of the way forward and require only minor adjustments, often with add-on modules, to do exactly what you want and to let the Web site owner control most of the decisions. Webform is less of a help, perhaps 50% or 30%.

So where do you use Webform? Consider the situation where you have to accept administrative input, perform a process, produce output, and, ideally, log the request. Webform can handle the user input and the logging. Adding a process behind a Webform form, instead of a conventional Drupal form, is as easy, or easier, than building a new form plus you get the logging built in for free.

Webform has lots of add-on modules to handle a wide range of selection choices. Adding your own selection option to Webform via a module is more work than adding something to a conventional form but once the option is added, you can use the option in any form.

If you have your selection options in a vocabulary, use the Webform term option module to give you all term lists ready made without coding. The value passed back is the term id, not the term value, and that is the only odd part of the processing.

Webform gives you the choice of several ways to see the processed result and a little bit of extra coding gives you many more choices. On one project the Webform approach required an extra day to add Webform in to the module code then reduced subsequence changes from three hours to twenty minutes.

Half of the extra day of work was generating a selection option module. The module required four hours compared to the forty minutes for a conventional code function. The selection option was reused and required only a minute on each occasion, compared to repeating the forty minutes previously required.

There are other ways to build the same type of interface. Many of the other ways reduce coding time but leave all the control in the code, limiting subsequent changes to the code developer. Using Webform for the user interface unlocks only part of the choices from the code. For some applications, the approach unlocks all the important settings and makes the less important ones more transparent.

The future?

The Webform style approach does increase processing overheads and content management systems, including Drupal, are continually moving toward more complexity to gain more flexibility. Hardware is improving in speed almost as fast as the software is slowing down. From the Web site owner's perspective, what is better, spending an extra $100 per month for faster processing or repeatedly paying a developer $200 for each change?

In the case of Drupal, the battle is evenly pitched between code developers pushing things into code and Web developers learning PHP so they can move pull things out of code and move them up to the user interface, preferably an Android pad interface.

Yes, there are also web developers using legacy machines to administer web sites, including Windows based notebook computers, iPhones, iPads, and netbooks, but the fight to move on from the previous decade is over. Android is the winner with Ubuntu on an Ultrabook trailing behind in second place. The clear losers are all the phones because the screen is too small and anything dependent on mains power because nobody develops sitting down anymore, the critical decisions are all made while walking across the road looking down at your Samsung Android pad.

Electric cars

Modern Web site owners are alive due to the noise conventional cars make. You get enough warning to look up from your Android screen. Electric cars are invading our roads and do not made the same level of noise. What is need needed in the next generation of Anpad (Andoid pad) is a set of cameras looking in every direction and coupled to motion detection.

Get it out of code

How do you audit code for things that should be outside of code?

Start with all the variables? Where does the data come from? The data should be from the users or the administrator. If any of the data originates in your code, get it out, make it an administration setting.

Now look at all the conditional logic. Does the code make any decision based on anything not specified by the user or the administrator? Get it out of the code and in to the administration interface.