Virtual Teams

March 15th, 2015 / Tales from a Trading Desk

Slashdot provided a few interesting links on Virtual Teams recently:

  • Why Remote Teams Are the Future (and How to Make Them Work)
  • Virtual Success: The Dark Side of Virtual Teams
  • 21 Months In: How to Manage a Remote Team

A few keys points are worth noting:

hiring people you can trust, and conversely, trusting the people you hire

Leaders that understand how to recognize and prepare for challenges and then raise solutions before they become costly stumbling blocks are setting themselves up for success. However, most leaders are taken aback by the diverse challenges that virtual teams can bring and spend the majority of their time attempting to assess what is going on and put out the fires.

Reading from Sockets

March 15th, 2015 / Hidden Variables

This post is part of a series on the byte sources underlying the readable streams in the Streams Standard. See the introductory post for more background and links to the rest of the series.

At the simplest level, sockets can be treated much the same as files. You can get a file descriptor for the socket, and while there are a number APIs involved in setting it up to actually connect to a remote server, once you’ve done that you can read from it using the same read(2) interface as we discussed for files.

Currency Language Support

March 10th, 2015 / Tales from a Trading Desk

As Anatole states in his “Go for the Money! JSR 354 Adds First Class Money and Currency Support to Java” post, support for monetary values is painful.  In the financial community, there should be a cheer to see that once JSR 354 is finalised in Q1 2015, development of complex currency applications e.g FX Single Dealer Platforms, should get a little easier.

Regards to anyone on Java 7, there is hope, but ideally you want to be looking to move to Java 8 in my view:

Random React.js Reading

March 8th, 2015 / Tales from a Trading Desk

General collection of React.js reading material.

Google Calendar Labs – World Clock

March 8th, 2015 / Tales from a Trading Desk

Yet again ran into issues using the World Clock experimental feature in Google Calendar.  Basically the world clock feature appears to be unaware of daylight saving changes in regions. The latest being the start of Daylight Saving time in the USA.  Net out, scheduling a conference call for 1:30pm NYC caused me to miss the call :(

Bank = Software Company

March 5th, 2015 / Tales from a Trading Desk

BBVA has made a bold statement about becoming a software company, predominately due to the change in mobile usage.  If I recall, Deutsche Bank had grand ideas of creating an internal software company at some point in the past – not clear how well that went.

I wondered what technology BBVA are using for their platform:

build a new customer-centric technological platform, which operates in real time and is also modular and scalable. This platform allows BBVA to develop a new generation of services to compete with new startups and major digital companies.

Reading from Files

March 4th, 2015 / Hidden Variables

This post is part of a series on the byte sources underlying the readable streams in the Streams Standard. See the introductory post for more background and links to the rest of the series.

Once you have opened a file descriptor, you’ll use the read(2) function to read bytes from it. In C the signature is

ssize_t read(int fd, void *buf, size_t count);

Translated into JavaScript this might look something like

const bytesRead = file.readInto(buffer, offset, count);

which will attempt to read count bytes into the ArrayBuffer buffer, starting at position offset into the ArrayBuffer. The returned number of bytes, bytesRead, might be less than the desired count, usually because you’ve reached the end of the file.

Byte Sources: Introduction

March 3rd, 2015 / Hidden Variables

This post is the beginning of a series of posts regarding some of the more interesting issues I’ve encountered while working on the Streams Standard.

In the Streams Standard we have the concept of readable streams, which are an abstraction on top of the lower-level underlying sources. In an abstract sense an underlying source is “where the chunks of data come from.” The most basic underlying sources are things like files or HTTP connections. (More complicated ones could be e.g. an underlying source that randomly generates data in-memory for test purposes, or one that synthesizes data from multiple concrete locations.) These basic underlying sources are concerned with direct production of bytes.

Complexity – Large-Scale Software Systems

March 3rd, 2015 / Tales from a Trading Desk

“Out of the Tar Pit” is an old paper, but worth a read never the less.  The paper was picked up in more recent years by Hacker School, and also “10 Technical Papers Every Programmer Should Read (At Least Twice), and more recently, Brian Gesiak.

Since Brian has offered a few interesting call-outs already, I’ll only offer a few additional thoughts/quotes:

Page 1: The biggest problem in the development and maintenance of large-scale software systems is com- plexity — large systems are hard to understand

Page 2: Complexity is the root cause of the vast majority of problems with soft- ware today

Event-Driven Architecture Pattern Topologies

March 2nd, 2015 / Tales from a Trading Desk

O’Reilly Radar has an interesting article on event-driven architecture, “Variations in event-driven architecture”.  Mark Richard’s eBook is available here if you want the full read.

Its probably worth pointing out that I’ve come across a number of people worried about the number of event queues when using the Mediator topology – a strange thought process in my view unless the architect is proposing to use a single queue for all event types :(

It is common to have anywhere from a  dozen to several hundred event queues in an event-driven architecture

Code Ownership

February 26th, 2015 / Tales from a Trading Desk

Jay Field’s has an interesting posting on code ownership, “Experience Report: Weak Code Ownership”.  “Too many cooks in the kitchen” is unfortunately a problem I suspect we have all seen to many times on medium to large projects.  Stating the obvious, encourage consistency on a large code base over n years is difficult – its unfortunate that stakeholders who haven’t come from a software engineering background don’t really grasp the issues of such problems.

User Story Map

February 19th, 2015 / Tales from a Trading Desk

Few useful links if your going down the User Story Map road:

Time to React.js?

February 18th, 2015 / Tales from a Trading Desk

Eric Florenzano offers an interesting read on “Facebook just taught us all how to build websites”.  Essentially he is talking React.js.  Given the noise level on the web around React.js, coupled with the recent React.js conference, I’d be surprised if readers don’t already have a view of React.js, and haven’t seen their peers/colleagues watching the various presentations.

A recent blog from the BBC offers insight into the road they are taking with the BBC Homepage refresh.  Unsurprisingly, the BBC has chosen React.js:

Bad Design Assures Bad Results

February 16th, 2015 / Tales from a Trading Desk

I’ve not read JavaScript Application Design yet, but was struck by the correctness of a statement made in “About the Book”:

The fate of most applications is often sealed before a single line of code has been written.

As I’ve blogged about before, all to often team lurch into code well in advance of actually understanding the problem they are attempting to solve, and lacking any sensible architecture and process.

Good design and effective processes are the foundation on which maintainable applications are built, scaled, and improved.

Technical Debt

February 12th, 2015 / Tales from a Trading Desk

Design Smells offer a single page on technical debt.  One of the key causes of technical debt often overlooked compared to the other items listed is “schedule pressure”.  Lack of understand of basic software engineering by stakeholders often means that teams are driven down a road where the only outcome can be technical debt, which in itself leads to other issues :(

Lean Enterprise

February 11th, 2015 / Tales from a Trading Desk

Got my hands on “Lean Enterprise: How High Performance Organizations Innovate at Scale” recently.  Found it a dry read.  However, the book has some classic comments:

The purpose of an organization is to enable ordinary human beings to do extraordinary things – Peter Drucker

Shareholder value is the dumbest idea in the world…[it is[ a result, not a strategy…Your main constituencies are your employees, your customers, and your products. – Jack Welch

Page 31, “establishing and trying to maintain effective communication within large teams consumes enormous amounts of capacity on large projects” – so so true.

Stop Writing Dedicated Server End Points – GraphQL

February 6th, 2015 / Tales from a Trading Desk

There are numerous interesting presentations from React.js Conference 2015. “Data fetching for React applications at Facebook” is one such presentation well worth watching.  Specifically the comment at 7:52!  Shaping data should also help with reduction of bandwidth usage – your only sending the data you need, and nothing more.  This blog posting provide a view on batching requests – cut down the chatter.

User Story Mapping – Reduce the Duplicate Stories, Improve Visibility

February 3rd, 2015 / Tales from a Trading Desk

Just finished reading User Story Mapping.  Although the concept isn’t new, the book offers a good read, which will hopefully improving the uptake of the practice by team in the construction and management of backlogs.  Few take aways:

  • Page 3 – “Stories get their names from how they should be used, not what should be written”
  • Page 23 – “Map for a product release across multiple teams to visualise dependencies”.  For me, “dependencies” is the keyword. Numerous times teams have failed to visualise dependencies of stories ending with discovery in game planning sessions and failed iterations :(

Event-Driven Applications in the Cloud – AWS Lambda

February 3rd, 2015 / Tales from a Trading Desk

Since the recent AWS Lambda launch, there have been numerous articles providing insight into the service.  What’s key from my perspective is that Amazon have enabled event from other services, thus making AWS Lambda a glue service for event-driven applications:

Lambda is launching in conjunction with a new Amazon S3 feature called event notifications the generates events whenever objects are added or changed in a bucket, and our recently announced Amazon DynamoDB Streams feature that generates events when a table is updated. Now developers can attach code to Amazon S3 buckets and Amazon DynamoDB tables, and it will automatically run whenever changes occur to those buckets or tables. Developers don’t have to poll, proxy, or worry about being over or under capacity – Lambda functions scale to match the event rate and execute only when needed, keeping your costs low.

Simple Made Easy – Complexity Will Kill A Project

January 23rd, 2015

Old, but great InfoQ presentation by Rich Hickey, “Simple Made Easy”.  The agile starting pistol (sprints) is very funny.

Simple = untangled