General Musing

Signals come from everywhere, they are tell us something about our environment. Whether it’s hot or cold, wet or dry, and painful or pleasant. These signals are rarely binary, there are gradients in the signals. And we have signals with which we aren’t dealing at that moment, which we’ll call noise in that instance. Feedback is also a signal, perhaps it causes a painful sensation or it causes a pleasant sensation. Whatever the sensation it causes that sensation too is another signal which we can choose to regard as noise.

Read the rest of this entry »

I recently saw a note from the Tech Journalist Russell Holly who calls on the Scumbags of the Internet to stop making demands of developers from whom they get their free software:

You don’t demand ETA’s on shit you aren’t paying for. You don’t get angry when something doesn’t work quite right on an Alpha or Beta build of something you didn’t pay for. You don’t start shooting off at the mouth about how you are going to move to someone else’s free software if this developer doesn’t fix the software you didn’t pay for.

I was naturally in agreement with the spirit of what he said. And I think that he and these developers miss a number of simple facts: Read the rest of this entry »

I first started writing about Wakoopa in 2009, when I wrote the article Time Spend, is Time Earned on using it for time management, it has mostly been running in the background to give me some statistics on the way I use my time behind my computer, and whether it is used effectively. Recently I started a new projects with new computers and again installed the Wakoopa Tracker to measure the effective use of my time. Naturally the Parato principle still holds, roughly 80% of the effects come from 20% of the causes.

Coriolanus effect: n. the act of going around in ever decreasing circles until one vanishes up one’s own backside.
–Glaswegian expression

For Sunday it is possible to see the amount of time I spend creating a Christmas card, and I see that – split over Mac and Windows – I seem to be spending the productive 62% of my office time on development, documentation and mail. Again I can also immediately see correlations between any dips in time – such as Monday – and real events, in this case meetings. Furthermore the relatively short time spend on development on Monday can be seen to have a ripple effect that continues on Tuesday and Wednesday. I’m sure that had the statistics been available for Thursday this line would continue.

Using my calendar I could get a similar graph, and although the details of how long I was “researching” a recent XKCD joke are still lots be lost, Wakoopa enables me to see the usage of my time slightly better and the collection is entirely passive.

Image source: Wakoopa

I like a User Story to be precise and target a specific functionality, a Use Case or a logical vertical of a Use Case. This means that a finely scoped task of 2 or 3 hours could be called small. It also depends at what time in the SCRUM backlog a certain User Story is implemented for it to be a small or large User Story.

At the beginning of any development project all User Stories are large, they include many additional variables everything from setting up the initial design patterns, to drastic refactoring to allow for stackable functionality. This means that a task which might take 2/3 hours once there is a working vertical to build on could take considerably longer when everything needs to be build from scratch. Ron Jeffries – SCRUM God – says Read the rest of this entry »

Recently I was asked by a client to make some estimations regarding a review of a code review for a programming project. The aim of the project is to refactor the existing code for efficiency, check the security and add new functionality. Having done code reviews in the past I had an idea on how it should be done, and little idea on how to quantify the work into an estimate.

How a code review estimate is done now?

Read the rest of this entry »

Having worked without RDBMS for much of the beginning of my carrier I have always been confused by people’s love of relational databases, in my mind they are merely a collection of CSV files with relationships, with some of extended capabilities that all other databases have such as indices and caching. I love that the concept of something that is not a Relational Database, or a complicated Key-Value store, has found it’s place in the world and it’s called NoSQL.

And didn’t we already have a solution which matched the requirements: scalable, ordered, hierarchical, sharded, consistent, atomic, distributed and object? And wasn’t it a key-value and document database with graph capabilities? An engineer wisely said: “Relational databases give you too much. They force you to twist your object data to fit a RDBMS.” What system doesn’t force you to twist your object data and still allows you to maintain the objects in the way you desire?

When we faced this issue we were having much trouble with a traditional database vendor and the mail software they were producing, we wanted to extend the capabilities of this software and not be reliant on the on-disk mailstores they provided. Mail should be stored distributed and be approachable from different angles, whether it is with a traditional POP3 client – the norm; a HTTP browser – emerging; or a IMAP4 client – which in those days was hideously complicated as the RFC had some features which were almost impossible to implement easily. We also wanted to be able to add USENET – which had the same format which we also wanted to be able to store, and even chat – be it IRC or private messaging. And while we were at it we might as well add FTP in the mix.

The external connections would be implemented in an Enterprise Service Bus design pattern, and the storage part was what posed the real problem. All of the data would need to be secure, distributed and/or sharded over multiple locations for efficiency and security. And with security as our first demand we thought of an open standard which we and almost the whole planet used and uses for their internal authentication. A database which has a key-value store at the core, based on a protocol extension written in round about 1993 and optimized in 1996. A database idea so SMART that every huge large software company in the world sells it: LDAP.

“LDAP?” I hear you cry, “That’s No NoSQL!” And you’d be right!

Image source: LinkedIn NoSQL Group

Testers are very important in SCRUM, before the sprint they help the Product Owner to refine the User Stories are help with “How to Demo” and “Definition of Done”. Doing this during backlog grooming or analysis meetings allows the Testers to suggest User Stories for testing such as in the sidebar, and allows them to product examples which can be used for automated testing, help with sprint planning, among others.

“As a Tester, I want to read a log, so that I can verify that payments have been processed”

During the sprint, while programmers will be implementing the functionality, the testers will be implementing manual test scripts, automated tests and acceptance tests associated with the user story. In some places they develop the automated tests paired with a programmer, and in others they script the tests themselves. The testers would deliver “Running Tested Features”, preferably together with the programmer, which comply with the Definition of Done which the Product Owner, Testers and Team have defined.

Read more articles on Agile, SCRUM or XP…

You can see that Testers are a vital part of any SCRUM team.

Image source: Wikipedia
Sources: Lance Walton, Henrik Kniberg

This week I went to the Kings of Code Conference, to “explore and discuss the latest trends, developments and best practices in web and mobile development technologies.” It included a hackbattle, lots of presentations and free beer.

HackBattle

Read the rest of this entry »

I had heard of The Quants and wanted to buy it, after my father and I discussed how it was that all this money disappeared during the credit crisis I thought it might be wise to get an in depth view of the “China syndrome hedge fund catastrophe.” This is more than just a review of the book.

The first thing that I noticed were the multiple references to Ed Thorpe’s “Beat the Dealer”, a book on card counting Black Jack using a Hi-Lo method, and “Liar’s Poker“. Both books are on my bookshelf. Liar’s Poker highlights the years 1985-1987 as a trader at Salomon Brothers. There is some overlap between the characters of the book, such as John Meriwether who famously was challenged to a game of liar’s poker for 1 million dollars and replied: “If we’re going to play for those kind of numbers, I’d rather play for real money. Ten million dollars. No tears.”

The book reminded me of playing the computer game “Capitalism” when I was 16 in which I would game the system by creating a company which produced a little profit and initially plowing that profit into buying companies by hostile takeovers on the mini stock market and then avoid the system creating more AI companies – it had a fixed number of AI companies and mergers would cause new AI companies to be created – by buying a controlling interest in the AI companies and forcing them to turn out high dividends until all the AI companies in the stock market were under my control. And leave the computer AIs to tend to the companies and all their business while the dividends pushed my company’s profit into 12 digits.

The Quants is less of a narrative than Liar’s Poker, much of it is carefully crafted from multiple interviews with most of the players, books, magazines and newspaper articles. The tale of hedge fund managers and traders taking ever increasing risk just to earn the same amount that they did the previous year is and as it notes “Hedge fund managers who’ve seen big losses can be especially dangerous. Investors [...] may become demanding and impatient. … [T]here can be a significant incentive to push the limits of the fund’s capacity to generate large gains [...] If a big loss is no worse than a small loss or meager gains [...] the temptation to jack up the leverage and roll the dice can be powerful.”

Even the glaring warning of Meriwether’s LTCM failure in 1998, like Daedalus’ warning to Icarus, it was ignored by most of the hedge funds. “By 1998, nearly every bond arbitrage desk and fixed-income hedge fund on Wall Street had copied LTCM’s trades.” They were leveraged up to their eyeballs, and while making huge debts of their own they traded with the debts of others, bonds, collateralized debt obligations and credit default swaps. Some hedge fund had leverages of 30 to 1, which means they borrowed $30 for each dollar they had as an asset. “Coming into 2008, hedge funds were in control of $2 trillion.” And the banks they were borrowing from had leverages of at least 9 to 1, because of fractional-reserve banking, these same banks “… Morgan Stanley, Goldman Sachs, Citigroup, Lehman Brothers, Bear Stearns, and Deutsche Bank, [...] were rapidly transforming from staid white-shoe bank companies into hot-rod hedge fund vehicles fixated on the fast buck…” These banks had “… trillions more in leverage that juiced their returns like anabolic steroids.”

And it wasn’t just the banks, insurance companies go into the action too. These insurance companies insured the credit default swaps, “[i]f the value of the underlying asset insured by the swaps declined for whatever reason, the protection provider [...] would have to put up more collateral, since the risk of default was higher.”

The light at the end of the tunnel is an oncoming train.
–Wall Street proverb

“… [T]here were legitimate concerns that as computer-driven trading reached unfathomable speeds, danger lurked. Many of these computer-driven funds were gravitating to a new breed of stock exchange called ‘dark pools’—secretive, computerized trading networks that match buy and sell orders for blocks of stocks in the frictionless ether of cyberspace. … In these invisible electronic pools, vast sums change hands beyond the eyes of regulators. While efforts were afoot to push the murky world of derivatives trading into the light of day, stock trading was sliding rapidly into the shadows.”

Conclusion

“The findings of behavioral finance .. had shown time and again that people don’t always make optimal choices when it comes to money [...] [N]euroeconomics, was delving into the hardwiring of the brain to investigate why people often make decisions that aren’t rational [...] Evidence was emerging that certain parts of the brain are subject to a ‘money illusion’ that blinds people to the impact of future events, such as the effect of inflation on the present value of cash—or the possibility of a speculative bubble bursting.”

To me it also looks like they were and still are blinded to money. Two great reads for the weekend.

Image source: Amazon

On the SCRUM Development list two questions often pop up, I call them the why and when of re-estimating. There are few defined rules on re-estimating, yet estimating and re-estimating is an important part of backlog grooming. Which is why this is a recurring question in many SCRUM fora.

Why should we re-estimate user stories?

Read the rest of this entry »