Journal Articles
| Browse in : |
All
> Journals
> CVu
> 301
(10)
All > Journal Columns > Editorial (221) Any of these categories - All of these categories |
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: Editorial: On Being Lazy
Author: Bob Schmidt
Date: 09 March 2018 17:17:37 +00:00 or Fri, 09 March 2018 17:17:37 +00:00
Summary:
Body:
I sometimes talk to people about being a 'lazy' programmer. Laziness in this case isn’t about laziness for its own sake, but it is about not doing things if you either don't have to, or if you know it’ll save you effort in the long run. An example of the latter is often about identifying manual, repetitive tasks and automating them to reduce time, as well as the opportunity for mistakes. It’s the former way of being lazy I want to look at here.
Not doing things you don’t have to is, of course, not a new idea – in programming, or elsewhere. It did garner a kind of popularity about 20 years ago, when Kent Beck and others were advocating ‘Extreme Programming’. One of the principles behind that was ‘YAGNI’ – You Aren’t Gonna Need It. It was mainly a reaction against the prevailing ideas of big up-front design, and spending time dreaming up features that ended up never being used. It’s a worthy cause, for sure, and also features in other lazy principles like doing the simplest thing that could possibly work (tm). It can be summed up as only implementing those features for which a concrete requirement (not just a wish) has been identified.
On the face of it, this seems fine, except that software development is never so neat and tidy. There are some non-functional or hidden requirements that are rarely considered by anyone except developers. One of these is application configuration. If a system isn’t built from the beginning to be configurable so it can (for example) be run on a developer’s workstation, or in any one of many deployment environments, it can be detrimental to the overall effort. It’s certainly the case that designing a system to be flexible like this can be difficult and time consuming, but I think it’s well-spent if it makes life easier down the road. It’s rare that something like this is identified as a formal requirement though, and back-fitting it can be very difficult.
There are many examples like this that seem to fly in the face of the YAGNI principle. Please write in with your own!
Notes:
More fields may be available via dynamicdata ..