Sparkling Water

•June 20, 2015 • Leave a Comment

H2O allows “users to combine the fast, scalable machine learning algorithms of H2O with the capabilites of Spark” – sounds all very intersting.  Having not had time to play with H2O it would appear that Flow is key to an almost like Clojure REPL (“Read-Eval-Print Loop”) environment. This in itself is interesting for the obvious reason of wanting a RAD environment to improve the models.

Fraud Detection is as usual one of the use cases offered by H2O.  I suspect however that financial companies maybe interested in H2O given the issues in the compliance world, especially after the LIBRO incidents the sector has encountered over the last time period.

Customer Intelligence from my perspective would probably be interesting to Proof of Concept (PoC) in the client trading space – think RFQ’s, think trading patterns, think pushing dedicated research to clients etc

Interesting time.

Anyone built any interesting PoC’s in H2O?

Tool Chain: Zed Attack Proxy (ZAP)

•June 20, 2015 • Leave a Comment

On the road to continuous refinement of the Continuous Deployment (CD) pipeline, I always find that teams often forget about security testing, in a similar way to performance testing.  Teams seems to focus in code, then aContinuous Integration (CI) process at the outset.  Only later when they begin to have conversation about the first prod release do they become aware of the need for CD.  At the point of CD, they are still not thinking real CD, and thus have overlooked the needs of security (and performance), and are still fixated on the code – not the cleanliness of code.

I’m therefore curious how many readers are using OWASP Zed Attack Proxy, or similar in their tool chain.

Talking with Tech Leads

•June 20, 2015 • Leave a Comment

Many people struggle when they move into a tech lead role.  Primarily because there isn’t a well defined reference guide in most organisation as to what a tech lead is.  This book offers some insight by stating the obvious, and interviewing numerous tech leads.

  • Page 17 – “Learning better time-management and task-management techniques as well as delegation skills will help you to cope.”  Classic management foundations.  Although obvious, it needs to be re-iterated and remembered.
  • Page 178 – Failure is a natural part of the learning process; it forces you to evaluate circumstances.
  • Page 240 – “Lessons Learned by First-Time Tech Leads”
  • Page 242 – “Lessons Learned by Practising Tech Leads”

If you do nothing with this book, read page 240 and 242 as the bare minimum.

Remaining technically grounded

Agile Product Management with Scrum

•June 20, 2015 • Leave a Comment

Whilst on a flight recently I finally got around to reading “Agile Product Management with Scrum”.  As usual the book, like most good books, offers at least a few reminders and new thoughts on concepts that are key to get correct on projects.

My main issue however is still that so many people involved in projects lack an understanding (and thus reading) in the reason for project failures (usually because they have no engineering interest).  This effectively leads to a high percentage of projects moving into an unacceptable risk area early on in a project, which only spirals causing teams and stakeholders to loose trust, focus and therefore inevitably money :(

If anyway, most corporations should probably consider mandatory training for all staff on some basic engineering principles, and the top 10 risks/issues that causes projects to fail.  Sticking your head in the sand on a project should not be accepted in this day and age!

Book commentary:

  • Page 19 – “Proxy Product Owner” – which can easily cause “conflicts and miscommunication, a slowdown in decision making, and a decrease in productivity and morale”.   Lack of engagement will always causes issues.  If you fail to engage, accept the consequences!
  • Page 29 – You really don’t need every feature under the sun for a Minimal Viable Product (MVP): “The original iPhone shipped without many features that were standard on existing phones: copy and paste, the ability to send text messages to multiple recipients, and a software development kit, for instance. These limitations, though, did not hinder its success. “
  • Page 68 – Non-functional Requirements (NFR’s) as constraints
  • Page 78 – Some relevant views on Fixed Price contracts.  Scrum is a disruptive process innovation!
  • Page 95 – Don’t be tempted to release more functionality by sacrificing quality.  Its key in my view to understand project engineering (as above), because without at least a basic understanding of software engineering, decision will be made that will inevitably mean money is wasted.
  • Page 103 – Just in time review – Don’t even think about not doing this, as it avoid the bubble at the end of sprints
  • Page 107 – Bungee Product Owner.  In many ways this related to the Proxy Product Owner.  Utter failure will follow
  • Page 108 – Unsustainable pace.  Another point often overlooked due to the naivety of stakeholders who lack any engineering/agile knowledge. Ultimately the team will fail leading to morale issues, resignations, and effectively a broken product. Wake up!

Like most agile books, use the knowledge appropriately.  The book is not a agile bible.  All projects have similar but different issues.

Artificial intelligence (AI) is the new User Interface (UI)

•June 11, 2015 • Leave a Comment

The article “Apple Finally Learns AI Is The New UI” provides an interesting view on Apple UI and Google.  The use of AI and intelligent search isn’t new.  Attivio has an interesting case study that discusses the advantages of its Active Intelligence Engine in the context of UBS Neo’s product – a unified cross-asset investment banking platform.  Worth calling out from the case study is:

An incredibly powerful search system is right at the heart of Neo

From the quote of Chris Purves, UBS Head of FX E-trading, the core concept that Neo has been build around is “Neo’s search”.  Neo search appears by the sounds of the article to data Period – “trading, self-commentary, research or equities”.  RMA add further context to Attivio’s case study from the perspective of the user experience strategy specifically targeting “ontology design and search engine design”.  Throwing Shadows add further details by providing us with a view that the User Experience centered around search engine design took a sizable team, “at the height of the project, there were 34 UX consultants, 11 being Visual Designers.”

Side note: The Neo (F35?) UX/PM Agile Process does look a little anti-agile from the workflow offered by Throwing Shadows.

Net out, given the trending with Big Data projects, once you’ve managed to access, clear and link the data, the insight gained maybe appropriate to channel into the user experience to move on from basic responsive design to AI Driven User Experience Design.

Low-latency Distributed Applications

•June 9, 2015 • Leave a Comment

Andrew Brook’s article, “Evolution and Practice: Low-latency Distributed Applications in Finance” offers a good read on low latency in finance.  RFQ’s and RFS are appropriately covered coupled with the often overlooked “Clock synchronization” :)  More thread than cores is also discussed – context switch.

Hopefully these types of articles will aid in educating people on the decision made during the design of low latency architectures prior to them being implemented, and deployed into production, with sometimes unfortunate results.

Its also worth calling out Aeron’s Design Principles:

To achieve low-latency with minimal variance, while achieving high throughput, it is important to define a set of design principles that guide the development. When a trade off is required then the design principles help guide the decision in choosing between competing alternatives.

There is no free lunch.  Performance comes at a cost – $ and/or time to develop.

Test in Production Environment

•June 9, 2015 • 1 Comment

Nice short article on application performance testing.  Its a shame that many companies still want to find excuses for not offering development access to production like environments:

Variables such as firewalls, specific load balancing configurations, server’s memory configuration, etc., may severely influence on performance. It is best to test in production or simulated production. This will tend to be done in a non-destructive manner. But the principle is consistent, test everything both physical, hardware and network to a full picture of what happens when the app is launched and used.

I’m sure there is a formula one could come up with that offers visibility to the stakeholders on how much money they will incur from a cost of not testing in a production environment prior to production deployment.


Get every new post delivered to your Inbox.

Join 693 other followers