Hibri's shared items

I received an email from Mark Muskardin, today, asking me some questions centered around how I ramped up and learned backbone, and looking for some good resources, too. I’ve had similar questions a number of times in recent weeks, so with Mark’s permission, I’m posting his questions and my answers here.

1) How did you ramp up on Backbone?

Mostly trial and error, honestly. I would try something to see if it worked or not and dig into the Backbone source code to find out why it didn’t in most cases. I also spent a lot of time looking at the example backbone code I could find in blog posts, in the documentation, etc.

In the end, though, it was really the throw-away applications I built that had the most impact for me. I would spend a few hours a night thinking about another way to approach a specific scenario in backbone, and try it out. In the process of doing this and exploring the different aspects of backbone, I learned a lot about how it works and how i like to work with it. (FWIW: I think this pretty well describe my learning style)

I also have a strong background in building windows applications with a model-view-presenter structure, in a composite application style. Backbone fits easily into my prior experience in this realm, so a lot of what i have been trying out and learning is stuff that i knew how to do previously, just putting it in to play in a different language and runtime. I think this gave me a pretty good advantage in terms of “things to try” in my throw-away apps.

Lastly – I started spending time keeping up with the Backbone mailing list, and the Backbone questions on StackOverflow. Try to answer questions, and seeing the answers that others provide has helped me a lot. Not knowing an answer often leads me to dig deeper into something in order to learn, so that I can answer, too.

2) Are they are any tutorials you’d recommend?

I tend to prefer tutorials that not only tell you what and how, but also why. So it shouldn’t be a surprise that I’m listing a handful of screencasts that I thought were tremendously informative. Every one of them has taught me a number of little details and/or given me a few ideas to try out.

(in no particular order)

• Peepcode: episode 1) http://peepcode.com/products/backbone-js and episode 2) http://peepcode.com/products/backbone-ii. The Peepcode series takes a client-side-first approach, saving the server communications for later (I think that will be episode 3 – which is being produced now, I hear)
• Tekpub: http://tekpub.com/view/mvc3/6 – This one is centered around integrating backbone with asp.net mvc 3. If you’re doing asp.net mvc work, this screencast series is a must-have. Even if you’re not, the backbone episode is excellent. I’m not doing any .net work right now, and I picked up a few tricks and new perspectives that I’ve applied to my code.
• Joey Beninghove: http://joeybeninghove.com/2011/08/16/backbone-screencast-introduction-views/ and http://webinars.developwithpassion.com/webinars/7 – Joey is a coworker of mine and is doing several screencasts / presentations on backbone. He takes a very detailed approach to each of the subject he’s doing.
• Refactoring to backbone: http://www.refactoringtobackbone.com/ – by Joe Fiorini. it’s not released yet, but i’ve talked with him about this a few times, and i love what he’s doing with it. the ideas is not to start with a blank slate, but to convert existing javascript code over to backbone

(Note: i’m also working on a very extensive screencast, but it won’t be available until probably late this year or early next year…)

There’s also the thoughtbook book: http://workshops.thoughtbot.com/backbone-js-on-rails. It’s a work in progress, but it’s worth keeping up with the progress. They’re doing a really cool thing with community involvement. I’ve been reviewing the book from time to time and offering suggestions for how to improve the book, now and then – as have a number of other people who have pre-purchased the book. There’s a lot of value in the book already, but it’s still in it’s early stages with much of it not being started yet.

Other than the screencasts and book, there’s a wealth of good backbone knowledge in blog posts, on the mailing list, and in the example apps in the documentation. Search around and keep your eyes open as new information is continuously popping up.

3) How do you test your Backbone apps?

For integration tests with the rest of my system, I use Cucumber. Most of the testing I’ve done with Backbone has been through Cucumber since I already have that in my Rails application. I set the tests to use the Selenium driver and run them as part of my normal Cucumber suite.

For unit testing (which I’ve been doing more of, recently) I use Jasmine and the Jasmine-jQuery plugin. My previous blog post addresses this, specifically to get my views under test with my view templates in place. (I’m considering writing a small series and/or e-book on testing backbone, though this is also covered in my screencast, so i may not be able to write an entire e-book on it any time soon.)

4) I saw that your created a Backbone plugin.  Does Backbone have a similar plugin/gem ecosystem that jQuery/Rails has?  How can I get started?

While it’s not as extensive as jquery or rails, there is a growing backbone plugin ecosystem. There’s also no automatic installation or package management like gems (or npm for node.js) or anything like that. Mostly, people just list their plugin in the backbone wiki, talk about it on their blog and on the backbone mailing list, too.

Before you start, you’ll need to understand object oriented javascript, if you don’t already. For this, I highly recommend the book “Javascript Patterns” by Stoyan Stefanov. Once you’ve got an understanding of how OOJS works, it becomes pretty easy to see how to extend backbone with your own code.

The real question, then, is not “how” but “what” or “why”… the two plugins i’ve written were built out of my own needs and desires to stop writing the same code over and over again. Backbone.ModelBinding is a collection of the patterns I was using for binding models to view elements, and grew from there. Backbone.Memento started as a quick hack to enable a cancel button on an edit form that I had, turned into a full memento pattern implementation, and started growing from there.

So, to get started… identify the common patterns in your own code, first. Extract those into something that a single project can use immediately. Then build and grow from there, as you see similar needs and variations in more and more projects.

Practice, Practice, Practice

The most important thing to take away from this, is that you won’t improve or really learn anything until you do it yourself. It’s great to talk theory all day long (and I love doing that), but without the experience that comes from practice – the art of doing for the sake of learning – it’s just an unproven theory. Get your hands dirty with some throw-away projects, see what works and what doesn’t, and begin to develop your own subtle and nuanced opinions and patterns based on this experience.

For the last few months I've been on an MVC 3 binge, learning as much as I can fit in my tiny brain. (Had to throw a few other things out first of course.)

Web Dev Conf New Zealand (WDCNZ), is in Wellington very soon (schedule on lanyrd), and I'll be talking there about all things MVC 3. This is keeping me awake nights, I can tell you.

I've applied to talk at the stack overflow dev days conference in Sydney in October. That would be an absolute blast. I rank my chances pretty low, but my excitement is high regardless.

Recently I talked at QMSDNUG, on 'MVC 3: Third Times a Charm', alongside Joe Cooney. It was a lot of fun, and we allegedly broke a record with our crowd size. It's basically a preview of what I'll cover in Wellington, though some material will be in or out as I revise.

(Higgins got another workout, and had some html5 goodness baked in)

I promised to put up the references from my talk. They're mostly about customizating your MVC 3 experience in Visual Studio. Here they are.

If you use MVC 3, what are your favourite bits? What would you cover in a talk? If you don't use it, why not? And what are the sort of things you'd like to see deomonstrated?

While deciding upon a data gathering activity, I ended up creating an activity which I have named: the quadrants for lessons learned.

Please find below picture depicting the activity. It has two axis: success versus failure, and planned versus unplanned. It has 4 quadrants: successful and planned, planned but failed, Unintended but successful, and Failed and not Planned.

The photo below is a result of this activity. As you can see, it generated lots of insights on lessons learned. The participants enjoyed this activity. It gave them lots of data points to talk about. I personally liked it because it opened our eyes for interesting quadrants, such as the accidental success or failure despite of planning.

After gathering the notes on the white boards, I asked each participant to use up to 5 dots on the cards he/she cares the most.

When I was at QCon London last year, there was much buzz around a talk about a new retail trading system. The thing that got people’s attention was its approach to achieving its high performance needs - reaching 6 million TPS. It does this by running all its business logic on a single JVM thread, getting high speed without all the complications of concurrent programming. This article describes the architecture they use to pull this off.

Perfection is hard to achieve in any walk of life and persuasion is no different. It relies on many things going just right at the crucial moment; the perfect synchronisation of source, message and audience. But even if perfection is unlikely, we all need to know what to aim for.

To bring you the current series on the psychology of persuasion I've been reading lots of research, much more than is covered in recent posts. As I read, I noticed the same themes cropping up over and over again.

Here are the most important points for crafting the perfect persuasive message, all of which have scientific evidence to back them up.

1. Multiple, strong arguments: the more arguments, the more persuasive, but overall persuasive messages should be balanced, as two-sided arguments fare better than their one-sided equivalents (as long as counter-arguments are shot down).
2. Relevance: persuasive messages should be personally relevant to the audience. If not, they will switch off and fail to process it.
3. Universal goals: In creating your message, understand the three universal goals for which everyone is aiming: affiliation, accuracy and positive self-concept.
4. Likeability: ingratiating yourself with the audience is no bad thing—most successful performers, actors, lawyers and politicians do it. Likeability can be boosted by praising the audience and by perceived similarity. Even the most fleeting similarities can be persuasive.
5. Authority: people tend to defer to experts because it saves us trying to work out the pros and cons ourselves (read the classic experiment on obedience to authority).
6. Attractiveness: the physical attractiveness of the source is only important if it is relevant (e.g. when selling beauty products).
7. Match message and medium: One useful rule of thumb is: if the message is difficult to understand, write it; if it's easy, put it in a video.
8. Avoid forewarning: don't open up saying "I will try and persuade you that..." If you do, people start generating counter-arguments and are less likely to be persuaded.
9. Go slow: If the audience is already sympathetic, then present the arguments slowly and carefully (as long as they are relevant and strong). If the audience is against you then fast talkers can be more persuasive.
10. Repetition: whether or not a statement is true, repeating it a few times gives the all-important illusion of truth. The illusion of truth leads to the reality of persuasion.
11. Social proof: you've heard it before and you'll hear it again—despite all their protestations of individuality, people love conformity. So tell them which way the flock is going because people want to be in the majority.
12. Attention: if the audience isn't paying attention, they can't think about your arguments, so attitudes can't change. That's why anything that sharpens attention, like caffeine, makes people easier to persuade. And speaking of attention...
13. Minimise distraction: if you've got a strong message then audiences are more swayed if they pay attention. If the arguments are weak then it's better if they're distracted.
14. Positively framed: messages with a positive frame can be more persuasive.
15. Disguise: messages are more persuasive if they don't appear to be intended to persuade or influence as they can sidestep psychological reactance (hence the power of overheard arguments to change minds).
16. Psychologically tailored: messages should match the psychological preferences of the audience. E.g. some people prefer thinking-framed arguments and others prefer feel-framed arguments (see: battle between thought and emotion in persuasion). Also, some people prefer to think harder than others.
17. Go with the flow: persuasion is strongest when the message and audience are heading in the same direction. Thoughts which come into the audience's mind more readily are likely to be more persuasive.
18. Confidence: not only your confidence, but theirs. The audience should feel confident about attitude change. Audience confidence in their own thoughts is boosted by a credible source and when they feel happy (clue: happy audiences are laughing).
19. Be powerful: a powerful orator influences the audience, but making the audience themselves feel powerful increases their confidence in attitude change. An audience has to feel powerful enough to change.
20. Avoid targeting strong beliefs: strong attitudes and beliefs are very difficult to change. Do not directly approach long-standing ideas to which people are committed, they will resist and reject. Strong beliefs must be approached indirectly.

Change minds

You should be aware that many of these factors interact with each other. For example when the message is strong but the source is dodgy, the sleeper effect can arise.

Argument strength is also critical. The basic principle is that when arguments are strong, you need to do everything to make people concentrate on them. When they're weak, it's all about distracting the audience from the content and using peripheral routes to persuade, such as how confidently or quickly you talk.

Weaving all these together is no mean feat, but look at most professionally produced persuasive messages and you'll see many of these principles on show. Incorporate as many as you can for maximum effect.

Image credit: Maigh

→ You can still get PsyBlog's creativity ebook at a 33% discount.

Here's a look at the latest data news and developments that caught my eye.

Registration open for Strata 2011

You can find out just what has us so excited about data at the O'Reilly Strata Conference, Feb. 1-3, 2011, in Santa Clara, Calif. early registration rates are available through December 14.

The Strata program features tutorials on data and visualization, an executive-level briefing event on big data, and two days of conference sessions and keynotes. We'll hear from big business, startups, and the brightest developers and researchers. Watch for further details about the schedule over the coming weeks.

We find ourselves at the beginning of an industrial revolution of data, heralded by unprecedented volumes of data and connectivity, cheap and ubiquitous computing, and advances in interface technology. Strata will be the defining event of this movement, so I very much hope you'll join us there.

From data to money: Building a startup

Thanks to commodity computing power, it's possible to build a startup business based around big data and analytics. But what does it take to do this, and how can you make money? These questions were addressed recently in blog posts by Russell Jurney and Pete Warden.

Jurney takes on the question of how many people you need to start a data product team. He draws out the ideal roles for such a team including: customer, market strategist, deal maker, product manager, experience designer, interaction designer, web developer, data hacker and researcher.

Quite the cast, and not really the ideal starting point for a product or business startup, so Jurney condenses these roles into the more succinct definitions of "hustler," "designer" and "prodineer" -- a minimum of three people.

Analytic products are such a multidisciplinary undertaking that in a data startup a founding team is at minimum three people. Ideally all are founders. There are probably exceptions, but that is the minimum number of bodies required to flesh out all these areas with passionate people who share the vision and are deeply invested in the success of the company. Someone needs to be good at and enjoy each of these roles.

Once you start, and have a minimal product, Jurney recommends quickly connecting with real customers, and taking it from there. The next step is making money, of course, which is what Pete Warden has been thinking about.

After running through a "thousand ways not to do it," Warden reckons finding a way to make money is the most important question for big data startups. He paints the stages of evolution a data product goes through to actually deliver value to customers.

• Data: You need it, but selling it raw is the lowest level of business. Warden writes "The data itself, no matter how unique, is low value, since it will take somebody else a lot of effort to turn it into something they can use to make money".
• Charts: Simple graphs, which at least help users understand what you have, but "still leaves them staring at a space shuttle control panel, though, and only the most dogged people will invest enough time to understand how to use it."
• Reports: Bring a focus to what the customer wants. Many data-driven startups stop here and make good money doing that. But there's further to go: "It can be very hard to defend this position. Unless you have exclusive access to a data source, the barriers to entry are low and you'll be competing against a lot of other teams".
• Recommendations: Your product now goes from raw data and produces actionable recommendations, a much more defensible business. "To get here you also have to have absorbed a tremendous amount of non-obvious detail about the customer's requirements, which is a big barrier to anyone copying you," Warden writes.

Ending his piece, Warden offers this pithy advice: "More actionable means more valuable!"

Data in the dirt

What would you say to a pub full of people about data? That was my challenge as I gave a talk at Ignite Sebastopol 4, held in O'Reilly's hometown of Sebastopol, Calif. Explaining some of the 200-year history of Strata, I had to use twenty slides for 15 seconds each to get my point across.

Dolphins, cellphones and social networks

A couple of recent research reports bring interesting insights from social networks outside of the online worlds of Facebook and Twitter. Writing in Ars Technical, Casey Johnston reports on how the mathematics of text messaging might help mobile phone networks plan capacity. Researchers discovered that text-messaging patterns were generally bimodal.

Text message sets often start off with a burst: the times between messages are short and follow a power-law distribution (that is, there are a lot of text messages with short intervals between them).

Outside of an initial two- to 20-minute window, though, the time between messages falls dramatically. There are fewer, longer intervals between messages, and the tail can extend up to five or six hours past the initial burst, as the intervals continue to grow longer and the texts less frequent.

The researchers took these observations, and developed models to explain what they saw. The model assumed that text exchanges were primarily task-focused, dealing with some issue the conversants had in common, such as deciding what to eat for dinner.

Cliques in a dolphin community noted in a Microsoft research report (PDF).

Intriguingly, two of the data sets the researchers tested their work on, which are apparently standard for this kind of research, were data gathered by anthropologists about a Karate academy, and data gathered by marine biologists about a pod of 64 dolphins. Applying their game-theoretic approach to both networks, they were able to resolve cliques that other approaches missed entirely.

Resolving cliques also has applications in determining identity, Mims points out. Individuals with non-unique names can be identified instead by the community footprint generated by their clique membership.

Gangsta test data

Perhaps one of the best known pieces of test data is the Lorem Ipsum text, used by graphic designers as a substitute for real text during the "greeking" process. This venerable text has now received an update for contemporary culture, courtesy of a couple of Dutch developers.

The Gangsta Lorem Ipsum generator serves up such modern nonsenses as Lorizzle bling bling dolor we gonna chung amizzle, consectetuer adipiscing dizzle.

Send us news

Email us news, tips and interesting tidbits at strataweek@oreilly.com.

What is CQRS? Well if we ask google it will say "did you mean CARS?" (although it seems for developers who search a lot it now actually comes up.

According to http://www.all-acronyms.com/CQRS CQRS is Commercial Quality Rimmed Steel

CQRS is none of these things. CQRS is not new. One of my favorite questions I get from people is "How many real systems are there running with this kind of CQRS stuff". The answer is ten if not hundreds of thousands. It even funnier when asked about Event Sourcing as I actually worked on a system 10 years ago using Event Sourcing (it used to be really popular).

CQRS is pretty much MVC!

I have had very few people notice this when teaching but occasionally a bright one will pick up on it. Of course CQRS is not precisely MVC but it is definitely a variant. Let's go way back to 1979 and look at what Trygve had to say about MVC. http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

MODELS

Models represent knowledge. A model could be a single object (rather uninteresting), or it

could be some structure of objects. The proposed implementation supports knowledge

represented in something resembling semantic nets (If I understand Laura correctly)

There should be a one-to-one correspondence between the model and its parts on the one

hand, and the represented world as perceived by the owner of the model on the other hand.

The nodes of a model should therefore represent an identifiable part of the problem.

The nodes of a model should all be on the same problem level, it is confusing and considered

bad form to mix problem-oriented nodes (e.g. calendar appointments) with implementation

details (e.g. paragraphs).

VIEWS

A view is a (visual) representation of its model. It would ordinarily highlight certain attributes

of the model and suppress others. It is thus acting as a presentation filter.

A view is attached to its model (or model part) and gets the data necessary for the presentation

from the model by asking questions. It may also update the model by sending appropriate

messages. All these questions and messages have to be in the terminology of the model, the

view will therefore have to know the semantics of the attributes of the model it represents. (It

may, for example, ask for the model's identifier and expect an instance of Text, it may not

assume that the model is of class Text.)

CQRS is also very similar to P-7: INPUT/OUTPUT SEPARATION in http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf 

The input and output aspects of the Editor are technically very different with few interdependencies. Their

UPDATE: New packages and further items

What a difference a year makes.  Last year at the first conference solely dedicated to JavaScript, JSConf 2009, there was a big focus on the uses of JavaScript on the client side.  This year, there was a marked change with server-side JavaScript taking up about half the sessions at JSConf 2010 this past April.  The rise of server-side JavaScript has been in large part to two platforms, Narwahl and node.js.  Node in particular has garnered a bit of attention lately, especially with the node knockout which happened very recently.  The winners in the node knockout competition alone should give you some clue as to its potential.

Why Node?  Simply put, the purpose of node.js is “To provide a purely evented, non-blocking infrastructure to script highly concurrent programs.”  This stands in contrast to many other concurrency models where threads and synchronization blocks are used, which can cause any number of issues.  Because of its lock free nature, and a bigger freedom from deadlocks, it allows for a more approachable way to concurrency.  The node.js site itself has a great amount of resources here to get started.

In this series, I’m going to focus a little bit on getting started on node.js and how you can mix the Reactive Extensions for JavaScript into your node solutions.

Getting Started

One downside has been in the past for me, being a developer who uses Windows frequently (given that I’m employed by Microsoft), has been the lack of native support for Windows.  Fortunately, with the release of node.js version 0.2, there is now support for Windows, albeit through Cygwin.  Following the instructions here, I was able to get it to install on any number of machines, from XP, to Windows 7 to Windows Server 2008 R2.   

When installing Cygwin, I chose the following packages:

• Dev (install all works just fine for all of them if space is not an issue, and I’d recommend that)
• gcc g++ C++ compiler
• gcc mingw-g++
• gcc4-4++ G++ subpackage
• git
• make
• openssl
• pkg-config
• zlib-devel
• Python – install
• Web
• wget

Once that installs, before you’ll be able to successfully build anything, you should do a rebaseall by doing the following steps:

1. Close any instances of Cygwin
2. Launch a command prompt
3. Execute ash.exe (commonly found in C:\Cygwin\bin)
4. Execute ./rebaseall –v

You should see results similar to the following:

/usr/lib/abc.dll new base = 1234, new size = 1234

Now it’s time for us to pull down a fresh copy of node.js.  You can either do it from wget and unpack it as the following:

$ wget http://nodejs.org/dist/node-v0.2.0.tar.gz
$ tar xvf node-v0.2.0.tar.gz

Or using Git, we can pull that down by the following command, if you installed Git of course like I told you to:

$ git clone http://github.com/ry/node.git
$ cd node
$ git fetch --all
$ git tag
$ git checkout v0.2.0

If you’re using a proxy server, like I was in several installs, you can get around that by setting the http_proxy environment variable:

$ export http_proxy=http://someproxy:1234/

Then you can start to configure and build such as the following:

$ cd node
$ ./configure
$ make
$ make install

Let this chug for a little bit and it should build just fine.  You can check for success by displaying the version of node such as:

$ node --version
v0.2.0

Another thing to notice is that we need to configure the DNS.  Although Cygwin itself relies upon the Windows DNS for its queries, node.js uses the c-ares library that relies on /etc/resolv.conf file.  Edit this file (if found, else create it) and add the entries to the Google public DNS entries:

nameserver 8.8.8.8
nameserver 8.8.4.4

Now, it’s time to set up our first file, called example.js and put it in the root of your node install, just for simplicity sake at this point.  We’ll create the typical web server example where we write our header and a body containing Hello World from Cygwin.

var http = require('http');

http.createServer(function (request, response) {
  response.writeHead(200, {'Content-Type': 'text/html'});
  response.end('<b>Hello World from Cygwin</b>');
}).listen(8124);

console.log('Server running at http://127.0.0.1:8124/');

And then we can start the server by the following:

$ node example.js
Server running at http://127.0.0.1:8124/

And now we can see the fruits of our labor by going to the address in our browser:

And there you have it, ready to roll with node.js on Windows (via Cygwin).

Conclusion

Here we’ve just scratched the surface of what we can do with node, now that it can be accessible to the many Windows developers out there.  Node, with its engaging community, is giving developers options for creating interesting scalable applications using JavaScript (yes, JavaScript).  In this series, I hope to dive a little bit into it as well as how the Reactive Extensions for JavaScript can play a part.

The most maintainable codebase that I worked with grew at a rate of about ~10 KLoC per month, every month. There wasn’t a large team there, it ranged fro 3 – 6 people. This is the project that I think about whenever I had to talk about good code bases.

It is a WebForms project (under protest, but it is).

What make it maintainable? Not the WebForms part, which wouldn’t come as a surprise. What make it maintainable is that it is the first project where I had applied the notion that large swaths of simple code is better than smaller code base with higher complexity. You could see example of this sort of architecture in the Alexandria and Effectus applications.

Note: I am doing things like measure KLOC here mostly because it is a number that I can measure. As I am saying in this post, KLOC has very little to do with maintainability.

The problem can be expressed well using the graphs. This is a representation of the complexity of the application as it grows, lower maintainability cost is better.

The problem with the smaller and more complex code base is that the complexity tends to explode very quickly. With the larger code base, you end up more or less on the same plane.

But the above chart is somewhat misleading, because it make the hidden assumption that in both code styles, you’ll have the same amount of code, which is obviously false. Here is what is probably a more accurate representation of how much code is written for style per # of features.

This doesn’t look right. Not when we compare it to the chart above. Of the top of my head, I would expect the second chart to be the mirror image of the first one. But it isn’t. And the reason that it isn’t is that each feature you write still cost you some amount of code. And the rate of growth per features added is pretty constant either way.

Putting the two charts together, you can see that it means that even code styles with focus on less code in favor of more complex solutions grow, and that as they grow, they become less maintainable.

So far I have been very vague when I was talking about “complex” and “simple”. In part, this is because those are somewhat hard to define. There would be people who would claim that ORM leads to complex codebases, but I would obviously disagree.

For my part, I also strongly advocate of having a strong core of infrastructure that gives services for the rest of the application, and that tend to be complex piece of coding. But that is also something that is fixed, once the infrastructure is written, it tend to be static, so that saves you from the fate outlined above.

When I look at a piece of code, I do the usual evals (nesting, conditionals, cyclomatic complexity, etc), but I also look at how often the developers reached for a hammer and beat everything around to submission. There is a lot of gut feeling here. But I do have one objective metric to use to tell you whatever a piece of code fit either style.

In the fight between Don’t Repeat Yourself an Single Responsibility Principle, SRP wins, every single time.

Any time that I have seem code that did double (or triple or dozenile) duty, it led to the sort of “we have to write less code” style of coding that ended up in a quagmire.