The Architecture of Morrisons OrderPad | Hacker News Reader

The Architecture of Morrisons OrderPad

martinfowler.com

30 pointsseansh24 comments

This is a very disappointing project. I would imagine the IT people who worked at Morrisons were rolling their eyes as the consultants came in and delivered a way over engineered / overly complex system.

The problems outlined in the article were solved with simpler methods 10 to 15 years ago. Why use a tablet at all? Symbol Technologies was making wireless handheld computers with scan guns 15 years ago.

In a modern supermarket inventory is updated every time an item is scanned at checkout. Spot checks of inventory are constantly being done to check for discrepancies.

The timing of orders was solved in supply chain applications years ago.

Whoever payed for this project I'm sure had a lot of nice meetings with the contractors. But in the end they got an overly complex system when off the shelf components in use for years would have done the job better and more reliably.

I'm seeing this trend a lot in the internet of things world. Basically there is a push to replace stuff that works with interoperable web technology based non solutions for . . . Cost saving purposes? Actually it always looks like a way to sell consultancy and hardware upgrades.

A lot of this seems based on the group coming in not actually getting how sophisticated that system they assume to be archaic really is.

Having developed software for point of delivery (similar market and devices) on Windows CE approximately 6-10 years ago, I would suggest that they did indeed pick the best solution to the problem now.

The symbol/intermec handhelds are expensive, terribly unreliable, slow, require a lot of maintenance and are terribly fiddly especially for people with gloves on (as you'd expect in the freezer department in Morrisons). As for the software development side of things, you're pretty much limited to a subset of win32 that isn't very pleasant to use or a mobile CLR which is so incredibly slow it makes you want to hang yourselves. Then there's the incredible deathly pain of deploying the code to all those devices.

It took us three years to deliver a point of delivery system with the same staffing level with much smaller scope which was simply signing for stuff and listing a delivery schedule. The integration was done by a third party - we just passed messages back and forth.

They did a damn good job at TW on this one if you ask me.

I disagree with you on a number of your points

I had different experience with industrial scanning equipment from reliable manufacturers. I found them to be reliable. They could be dropped and still function and they had a much wider functional temperature range. If the operator is wearing gloves I would expect that the environment is outside the functional temperature range of a tablet.

As for the software development side of things, you're pretty much limited to a subset of win32 that isn't very pleasant to use or a mobile CLR which is so incredibly slow it makes you want to hang yourselves. Then there's the incredible deathly pain of deploying the code to all those devices.

There were many devices that supported OS's other than Windows CE as well as Windows CE device that didn't require the CLR for applications. There were also thin client models where the code executed on the server which made deployment much simpler.

You had a remarkably tolerant customer.

They did a damn good job at TW on this one if you ask me.

I disagree.

This is a good question. I worked at a small grocery chain (a dozen stores or so) that did a lot of their IT ad hoc. I wonder if the big consulting firms don't care or are too high priced to work with smaller businesses. Small business seems to be in a twilight zone between enterprise and consumer software. Not that there are not good reasons for this. I have found small business owners to be stingy and demanding. (Again, for legitimate reasons - their business is their baby and they can take it very personally.)

The strategy with the tablets might be broader than this project with other (perhaps coming in the future or from different teams) functionality that the handhelds you mention cannot deliver. How capable are these wireless handheld computers?

The wireless handheld computers are targeted at very specific functions. They do those functions very, very well. The functions in question are critical enough that they justify specialized hardware.

> (4/25) We needed to support working offline should the user go out of range of wi-fi.

> (8/25) When offline, any actions that require a GET to the server results in an error message to the user.

I would argue right there that you failed to deliver a product that met the user's requirements, and this sort of limitation is why I have to write native code when writing a web app would be much easier.

> (21/25) Development team consisted of 5 developers, 1 business analyst, 1 tester, and 1 project manager (times 2 years for development time)

> (21/25) Production code is 20K LOC of Java, 10K javascript.

I'm not sure on what planet that is considered a reasonable level of output, but it must be nice there.

We don't know what the user's requirements were. It's possible that they minimized the required GET actions but that some actions required GETs because the data needed to be real time accurate.

In-memory and offline storage are possible in web apps.

Output should be measured by saving costs or new revenue, not lines of code written.

And it's a lot cheaper to over specify a cheap wifi network then it is to try to solve the problem with software in applications.

Regarding the need to do a GET when not connected: How would a native app solve this problem any better? Presumably, there's live data that sometimes needs to be fetched. If you're not connected you're not going to get that data whether you're in a browser or an app.

My favorite solution for this periodic offline/online access is CouchDB for mobile or PouchDB for html. But it's use would require another device between the back end CouchDB and their Oracle server.

Certainly better than a planet where effectiveness is measured in terms of number of LOC produced.

I wonder what quantity of code / time was spent on building their custom jquery-based application framework. Or maintaining it.

On slide 6/25, why would you not do a straight 'update order quantity' and 'sendUpdate' using JQuery? (last 2 steps, ok apart from checking the size limit). Why all the ceremony in between? (genuine question).

I'm reading a lot of Not Invented Here in that front-end stuff - building your application on top of jQuery is terribly pre-2012. I bet they spent a considerable chunk of time on that.

Heaven forbid that they go with something stable with which they have years of experience delivering products. Desperately uncool.

Is the two-year timeline reasonable? (ok, the 1st version to production took 7 months)

Ok, so they have more testing code than business code, this is not a "quick and dirty" app, but it still looks like a long timeline and a large team for the app's description.

Is the two-year timeline reasonable?

I really hope it isn't. I've made much shorter estimates for a nearly identical application, with time penalization clauses.

"since all the data is stored inside the DOM as field values or HTML data attributes."

That doesn't seem like a very good idea. Seems like the opposite of what we've been doing for the last few years.

If "what we've been doing for the last few years" means two-way binding of data models, then I agree that either that or using direct field values is a bad idea but the one I am thinking is bad may not be the same one that you are.

The presentation is nice. Does any one know if the tool used for generating type of presentation is available?

It would be great format for presenting to upstream project management and friends.

I suspect thats its a custom tool set [1]

[1] http://martinfowler.com/bliki/Infodeck.html

Reply on news.ycombinator.com