Hortonworks seems to have done a good job on offering Hadoop tutorials, leveraging a Sandbox. In particular, they offer a real-time event stream with Apache Kafka which is then persisted into HBase and Hive using Storm Bolt. Food for thought
You’ll always hear about the Definition of Done (DOD) from agile teams. However, what is not so often discussed is Definition of Ready (DOR) – sometimes referred to as DevReady in various organisations. Fabrique’s SXSW 2013 slide deck (53) offers a view of DOR. The Agile Alliance crystallises why DOR is important:
Avoids beginning work on features that do not have clearly defined completion criteria, which usually translates into costly back-and-forth discussion or rework
Churn during iteration due to imprecise requirements is often the by-product of not having a strict DOR.
Test-first methods can be further divided into Test-Driven Development (TDD) and Acceptance-Test Driven Development (ATDD). Both are supported by Test Automation, which is required in support of Continuous Integration, team velocity, and development efficiency.
Beauty of Testing (Steven) offers a few home truths which unfortunately are seemingly lost in the rush to make a production release by people not aware of the complexity of software engineering (and it not being an exact science):
Too often if the project is late or hurry up and learn or agile methods are employed, testing is one of those efforts where corners are cut.
Its nice to see that Steven appropriately calls out “specification”. All to often the concept of specification is lost in an agile project, leading to debate about a bug, and comments centred around “its obviously”. Ambiguity exists unfortunately in all walks of life, and hence the need for a specification. No specification, no bugs.
For example, no one builds as much as a kitchen cabinet without detailed drawings with measurements. Yet routinely we in software build products or features without specifications.
WallStreet & Technology offers a view on Single Dealer Platforms (SDP). Over the last few years there have been a number of articles stating that SDP’s will either take over the world, or are a dying breed. The net out of this latest article is unsurprisingly a view that Single Dealer Platforms and Multi Dealer Platforms will be combined by either banks or clients to offer a subset of services based on the clients needs – best of breed (effectively a type of mashup).
Further, the article hints at the opportunity for non-bank/clients to offer custom aggregation SDP/MBP. Obviously, this is easier were SDP/MBP’s already offer features via FIX or similar API’s. However the problem area will be in the User Interface (UI) space, where for example a client wants Bank A’s FX functionality, Bank B’s Bonds, and Bank C’s Repo’s. It becomes even more complex if a client wants a subset of an asset class – unless of course the UI has been built in a very modular way. We’ll ignore the single sign-on issues for now.
Part of the solution maybe the App Store concept that Apple has helped drive into so many markets. Deutsche bank has such an App Store offering. As to how well it would work in the SDP/MBP aggregate arena is another question.
Great post from Slava @ReThinkDB. Some great lessons. 32 – news doesn’t age well! 21 – Leadership is important
Further, Slava offers some view on project management – of particular note, treat big projects with care. Of particular importance:
build the absolute most minimal version that solves the customer’s problem.