It's a sign of a healthy society that the validity of an official version of history may be openly queried.
It's also healthy that an official version of history (of course everyone is entitled to maintain their own personal version) be managed by accepted academia (i.e. peer reviewed, by publishing in established independent media; journals, conferences, etc), who are constrained for the sake of their reputation to backing up statements they make with academically verifiable evidence.
The way to change history in this case is to invest the time required to do it through academic channels. That would usually involve getting a Ph.D and because of the rigor necessitated by this approach, is usual only feasible to do a bit at a time.
The other way to change history is by war - revolutionary change to an official version of history can be achieved this way. A version of history implemented by war works for the winner; for the group of people that they manage to win rule over and for as long as they choose to operate a dictatorship.
Perhaps all official histories started out by being imposed by war. As peace ensues though and as academia becomes free to explore, official history becomes decreasingly biased.
Friday, 8 July 2016
Friday, 28 August 2015
I wrote this blog post about a year ago - have finally got around to putting it online. It uses a "genericised" system called UpdateManager to demonstrate how to set up code coverage analysis for .NET. Hopefully it's not too dated just yet...
TestDriven.NET is a tool that is primary intended to support unit test development, but it has a lot of overlap with ReSharper.
What is unit test code coverage benchmarking/analysis?
Unit test code coverage analysis essentially tells us "how much of my codebase is covered (or "exercised") by my unit test suite?"
When we are writing unit tests, it is necessary to visually scan the codebase and get a feel for what degree of coverage we have and what parts of the codebase are important/relevant for unit test.
Setting up a benchmark such as "a standard .NET codebase must have at least 70% unit test coverage" can be useful, as although this is not a fail-safe way to make sure that we are testing the right things, we can at least be certain that if our metrics indicate we meet the benchmark, most of the important stuff will be tested.
There are several tools available that will provide this sort of metric on a .NET codebase - including NDepend, NCover, etc.
TestDriven.NET vs ReSharper
If you're already using ReSharper currently (as many .NET development teams do) - and given the fact that ReSharper generally has superior functionality where there is functionality overlap with TestDriven.NET - there is not a lot of value for us in having an additional tool for this purpose.
TestDriven.NET however supports one function that ReShaper lacks - which is unit test code coverage analysis - TestDriven.NET has a built-in instance of NCover, which can be accessed like this:
[Getting to NCover from TestDriven.NET]
When NCover is run across a unit test library, it will run all your tests and provide a code coverage report (percentage coverage of codebase by unit tests), that looks something like this (see the Output window of VS2010):
Following that NCover will open an interactive explorer app/window called “NCoverExplorer” – like this:
Using NCoverExplorer, you can browse the codebase (by namespace) under test that has been analysed by NCover and establish the percentage that each assembly, namespace, class and event method/property is covered by unit test.
[NCoverExplorer window - browse to assembly]
[NCoverExplorer window - browse to namespace, etc]
Setting and adhering to a code coverage benchmark (and tooling up accordingly) is a step along the way to establishing a mature, modern software development practice.
Adopting unit testing as a practice by itself is extremely important. However, code coverage benchmarking and analysis provides the on-going measurement and reporting that is required to be able to sustain the practice.
TestDriven.NET and NCover provide a way to get started with adopting and learning this practice relatively cheaply. TestDriven.NET is free for personal use.
When TestDriven.NET is installed over the top of ReSharper, it can sometimes "replace" some of ReSharper's very nice unit testing automation functions (such as those neat little green dots on the left side of the text editor that will launch a test for you and indicate the most recent result).
[ReSharper - neat little green dots for running tests]
Never fear - in order to get ReSharper's functionality back, just re-install ReSharper back over the top of TestDriven.NET. It's a bit of a "sledge hammer" approach, but you only need to do it once, and it works.
Friday, 2 January 2015
Preamble, background, etcScrum is a process improvement framework that has grown up within the world of software development and/but is increasingly used not only within the world of software, but outside of it also. Scrum in-fact lends itself well to product development in general. This post focuses on Scrum (and frameworks like it); in particular how it copes (or doesn't cope) with significant organisational change and where/when improvisation becomes more important than a framework.
The following links provide some information about Scrum:
- A 1986 HBR article that introduces the basic concepts: https://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG
- The Wikipedia page on Scrum: http://en.wikipedia.org/wiki/Scrum_%28software_development%29
An acquaintance of mine recently asked an interesting question about Scrum...which was essentially:
"What do you do when an established Scrum team encounters a serious problem?"
["What do you do...what do you do...?" - source: http://chaffeenguyen.com/win-win-situations/]
As a process improvement framework, Scrum is able to cope effectively with most of the day-to-day problems that an organisation may face. Occasionally though the problem is simply a mismatch for the framework - just too big. For example; the business has changed hands, management has changed and/or the business' strategic direction changes.
Scrum works great when business is relatively smooth; it surfaces problems to be resolved by the team/business, etc. Beyond a certain size/volume of problem(s) though Scrum seems to become impractical. What emerges then is a need for the team to lean more heavily on it's ability to self organise and improvise - outside of any framework - in order to be able to recover effectively or perhaps survive. For this reason, I have come to think that drilling a Scrum regime across an organisation is not necessarily always best for business.
Strategy and the importance of improvisationTo reach their true potential, teams need to have the freedom to explore, develop and optimise their own capabilities within themselves and outside of any set framework. Rigorous adherence to a framework can mar the natural and relatively fragile team-gelling process. Another trade-off to rigorous adherence to a framework is that a team's improvisation skills become rusty. And the ability to improvise in particular is key not only in emergency situations but also (arguably, more-so) in day-to-day business.
[Miles Davis; exemplary improviser - source: http://www.fastcompany.com/3000340/if-miles-davis-taught-your-office-improvise]
Furthermore, in reality, business is not about trying to get things to go as smoothly as possible - to survive and be prosperous, a business must seek out and overcome difficult challenges. If we focus on "getting to smooth" then we invariably begin to steer clear of challenges (AKA opportunities).
A successful business (or one that at least plans to succeed) will have strategic direction and in alignment with that strategy some challenges will need to be avoided. More importantly though a business' strategy ideally will generally - and openly - identify the type of challenge that it wants to line-up and engage. That way at least everyone knows what the intention and direction of the business is and can have a feel for what's right and what's not.
Of course, engaging and avoiding challenge is a balancing act that needs to take in to account resourcing, scheduling, cashflow, etc. Shying away from challenge purely in the interest of maintaining stability though is essentially laziness or myopia. Of course, this is deadly in business - remember Kodak? MySpace? Etc.
Where am I going with this in terms of the framework...? Well, from a strategic perspective, the framework is simply a tool that's there to help a business reach it's strategic objective. Interestingly, working within the framework it can be difficult to identify if/when the framework itself has become a problem. It can happen though, especially in times of significant organisational change - a framework can in-fact be used as a shelter; a means to avoid or delay dealing with organisational change openly. In this situation things can become fuzzy and political - so I won't take this line of thought any further. I wanted to at least identify this point as part of this post though.
Is the framework still relevant?So, certainly not suggesting that Scrum and frameworks like it are rubbish - far from it - they can help new teams get a great kick-start and can provide a clear ramp-up for organisations new to Agile.
[Bamboo scaffolding, Hong Kong - source: http://www.archdaily.com/tag/architectural-photography/]
What I am suggesting is that beyond a certain point - whether it's due to an organisation reaching a certain level of maturity or an unavoidable and significant organisational change - the framework may become irrelevant and perhaps even cumbersome. It's worth being aware of this as a possible scenario, and if possible maintaining a general "feel" for a framework's relevance within the organisation.
Agility/stabilityIn my opinion, Agile essentially still holds the key in times of challenge and uncertainty. Outside of any framework, the basic principles of the Agile Manifesto (http://agilemanifesto.org/) seem to hold true; providing a simple, value-oriented sounding board when things get awkward/ambiguous, and a clear guide back to stability - until the next time!
Thursday, 6 November 2014
What is MyBigBro?
MyBigBro is a system I have built that tracks a user on their journey through a city and captures and stores imagery of them that has been made available on the city’s CCTV traffic camera network, as they move through the field of vision of each subsequent CCTV traffic camera.
Why'd you do that?
There is a growing trend among Governments globally to make the data that they collect on their citizens as open and available as possible. The MyBigBro 'experiment' (I'll explain why I call it that later) explores this trend and leverages some of the data that is becoming accessible.
Some examples of open dataset repositories provided by Government are as follows:
- New Zealand: https://data.govt.nz/
- United Kingdom: https://data.gov.uk/
- Australia: https://data.gov.au/
- USA: http://www.data.gov/
One of the datasets that I find particularly interesting is CCTV traffic camera imagery. MyBigBro leverages that specifically.
How does the MyBigBro experiment work?
At the time that I originally wrote this document (which was originally a pitch for funding, and has now been hacked and re-purposed for this blog) MyBigBro was in deployed on the Android app store "Play" and in early alpha - not publicly available. There were (and still are!) a number of features yet to be developed before it was properly ready to introduce it for public use - it's now publicly available.
[Images captured while travelling though Mangere Bridge, Auckland]
[Last image in the sequence above - https://s3-ap-southeast-2.amazonaws.com/mybigbro/d9a2b564-2c5b-4a45-b5a0-89adea1a12cc.jpg]
The MyBigBro system architecture leverages a range technologies. Although the following diagram references AWS elements, currently MyBigBro sits mostly on the Azure cloud platform; the fundamental architecture has not changed significantly however since I drew the diagram in early 2014:
At the time I was using AWS and a local webhosting organisation (http://www.kiwihosting.net.nz/) for hosting purposes. The back-end services are now almost entirely running on Azure. No clients other than the Android one exist at this stage.
[The MyBigBro system architecture]
At the time I was using AWS and a local webhosting organisation (http://www.kiwihosting.net.nz/) for hosting purposes. The back-end services are now almost entirely running on Azure. No clients other than the Android one exist at this stage.
Development and potential; thoughts
Development on MyBigBro has been underway since mid-2013; my efforts ramped up in early 2014, following my completion of a two year part-time study programme last year. The idea first came to me sometime in 2012. I suppose I get between 1 and 10 hours per week to spend on this initiative, sometimes more, sometimes less.
Over the coming months and years I anticipate many city's CCTV traffic camera networks will become more advanced; the cameras will become higher resolution, the images will be refreshed at closer intervals and the camera networks will become more granular (we are already seeing this in
NZ). Currently images being captured from the NZ network are “hit and miss” as to whether the participant is captured, due to the CCTV image refresh intervals and the resolution of the cameras. As the camera networks develop though, users of MyBigBro will be able to capture images of themselves increasingly regularly.
At the time of writing (Nov 2014) MyBigBro is limited to New Zealand, Sydney, Hong Kong and London’s CCTV traffic camera networks. London is (currently - only just) of most interest, since the CCTV camera network there is vary granular and covers a rich range of urban settings.
[App screenshot showing a sample image picked up by a test user in London - https://mybigbro.blob.core.windows.net/images/55552a1b-9ffe-4336-a094-032f8b0d3650.jpg]
Further information relating to London’s CCTV traffic camera network is as follows:
Theme and market
The theme that I am developing could perhaps most accurately be described as “gamification” of issues that are of public interest, such as public sector CCTV infrastructure. The front-end (web and mobile app) is a novelty, which appeals to our general curiosity with regard to what data our Governments are collecting about us and making available to the general public. The product is mildly tantalising, but is not a tool or a necessity. I'm not certain what the market for MyBigBro is as a service, but can speculate...
The intention of the system at this stage is to capture imagery from cameras as users move through a network of CCTV cameras. The system could be adapted easily though to capture and store a series of images from a single camera indefinitely. This would be useful for example if a user wanted to keep an eye on their car overnight, which they had parked and left in the field of view of a camera.
MyBigBro is not really a business or a productivity tool – it is more like part of an experiment. However, given the current attention that issues relating to public sector data collection and distribution are receiving, MyBigBro does have the potential to become a point of interest in cities like London, where Government CCTV use is pervasive. Follow-on opportunities may arise as interest in the platform grows.
How can I get/use MyBigBro?
As mentioned above - the app's currently only any good to you if you use NZ's motorways, or Sydney, Hong Kong or London's streets. That being said, here's how you can get started:
- Get the app: https://play.google.com/store/apps/details?id=com.infostructure.mybigbro
- Visit and fnd your way around the web app: http://mybigbro.tv/
- Run the Android app (background is fine), traverse your city, look-and-see on the web app if any images are captured.
- Ask questions: https://twitter.com/mybigbrotv
Easy as 1, 2, 3...4!
Why "My Big Bro"?
So if you have not guessed; I call this experiment "My Big Bro" after the character "Big Brother" in George Orwell's book 1984. This is a loose reference to the way that the system sort of, claims back some of the data that is collected by a/the Government on it's users. Thus, MyBigBro is (part of?) a social experiment, or perhaps (more accurately?) an artwork.
[Banksy's "One Nation Under CCTV" - source: http://londonist.com/2008/10/council_to_remove_banksy_mural.php]
To clarify - I am not a conspiracy theorist and this is not a political manoeuvre. I do actually consider MyBigBro to be an experiment; a piece of art, like an installation artwork. I'm interested in the changing nature of our cities and the role that Government CCTV has to play in that. I'm also interested in image processing and computer vision.
Mainly right now, I'm interested in people using MyBigBro and generating data - so if you know people in London in particular - tell them to install it and tell them to tell me if they reckon I've bollocksed something up!
Monday, 13 October 2014
Thoughts on team dynamics...This blog post is a loose assembly of some of my thoughts on communication, thought and culture - and the importance of making room for these processes/phenomena to develop when we are working to solve complex problems in teams.
Two important referencesPerhaps you have heard the following commonly repeated quote of Abraham Lincoln: "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." - essentially, before diving in and starting a job, it pays to think about how to approach it and prepare.
The following link will take you to a more detailed version of the same thinking with specific reference to software development - "We Haven’t Got Time to Think about This Job, Only to Do It" (Peopleware - Timothy Lister and Tom DeMarco, 1987) - if you're lucky, Google will let you read to the end of chapter 2, which is where this section is.
I actually highly recommend the book "Peopleware" in general for anyone working with software development teams; at least take a look at the section referenced above (if you can reach it).
Anyway, these references set the stage for the remainder of this post.
Teams, communication and gestaltWithout communication we can end up doing a lot of hard work to produce something that is mostly useless (worst-case-scenario!).
It is better (in my opinion) to at least accept - and ideally expect - that a percentage of a team's time will be spent purely on maintaining/developing cohesion and culture.
A team is an entity in itself - the German word "gestalt" (for which I believe there is no analogy in the English language) essentially means "the whole is greater than the sum of the parts". This is what a team is like.
Think about it - if you have ever been part of a close-knit team (a football team, family, organisation, etc - most of us have been), you will know that they can be happy, sad, motivated, dysfunctional, hurt, inspired, etc. A team is like a living, intelligent being in it's own right; it is capable of achieving more than the sum of the efforts of the people from whom it is composed. It is born of two or more minds working toward a common cause.
Teams function optimally when they are allowed/enabled to blossom and thrive. One of the reasons people leave teams is when they have no spirit.
Agile meetings - how can we improve?Meetings are important. It is true that some meetings are unnecessary - and should be called out - but it is important to lean toward giving the benefit of the doubt.
Agile meetings such as stand-up meetings, sprint reviews, sprint retrospectives, sprint planning and backlog grooming give us a framework that we can use to develop a healthy level of team communication.
It's important to have a technical understanding of the purpose of these meetings and use them as intended.
It is far more important though to understand the principle these meetings are founded on; that in order to optimise productivity, teams need to be given the opportunity to figure out for themselves how best to communicate and to manage their work.
Agile meetings - a taxonomyHere are a few articles that I find useful to revisit sometimes as an overview/refresher of the various meetings that Agile prescribes:
- Further thinking on Stand-Up meetings: http://martinfowler.com/articles/itsNotJustStandingUp.html
- What is a Sprint Review meeting: http://www.mountaingoatsoftware.com/agile/scrum/sprint-review-meeting
- What is a Sprint Retrospective meeting: http://www.mountaingoatsoftware.com/agile/scrum/sprint-retrospective/
- What is a Sprint Planning meeting: http://www.mountaingoatsoftware.com/agile/scrum/sprint-planning-meeting/
- What is a Backlog Grooming meeting: http://guide.agilealliance.org/guide/backlog-grooming.html
In summaryAgile meetings provide a framework that we can use to ignite team communication. They are not the only way of doing this, just a way that has been shown to be effective. This post is not about Agile meetings - it is mostly about team communication.
Effective teams are empowered enough to take advantage of meetings and to use them as a means of internal and external communication. Flavours of Agile like Scrum can give us a guideline for how to use meetings optimally.
By definition, teams are the only means by which organisations get things done (who knew?!). Managers are important - their purpose in the context of the team is to facilitate and to enable team communication.
Sunday, 5 October 2014
Grace HopperThis lady coined the word "debugging", when she found a moth in a piece of computer hardware that she was writing code against:
[debugging 4 realz - source, Wikipedia]
Julie Ann HorvathIs probably the most recent famous female computer programmer, after she left GitHub in a major huff:
This is a bit of a sad story and it is a shame that it was allowed to happen. Up until just recently, GitHub lauded the fact that it didn't need managers:
So really this story reminds us why/how managers are important - good management would most likely have prevented this situation from going so badly wrong.
Women's work...?Interesting to note that programming in-fact used to be considered "womens work" - but now most professional programmers and computer science/engineering students are male (in NZ).
So what changed...? Here's one writer's take on the situation (YMMV):
In any case, if you work in software and have even a few female techies on your team, you probably have a more balanced mix than most organisations (at least in NZ?)
Ada LovelaceLast but by no means least - this lady wrote what is now recognised as the the very first computer program:
The Ada programming language was named after her and was one of the first object oriented programming languages:
[Ada Lovelace - not your stereotypical computer geek - source, also Wikipedia]
Sunday, 29 June 2014
Writing code and developing software is a creative act. A programmer who finds herself in her work wields her tools and applies and refines her craft with as much care and discipline as any other type of artist. Anyone who has ever written software and/or developed an artwork in anger will be familiar with the dual processes of working toward a clear goal or idea, and coaxing an expression into existence through incremental experimentation and failure.
To illustrate this notion I invite you to take a look at Picasso’s artistic process, dear reader:
Perhaps you are not comfortable with an analogy of art/painting for programming? Then the following analogy for programming as gardening may be easier:
["Rather than construction, programming is more like gardening" - source: http://www.artima.com/intv/garden.html]
In any case, the idea that I want to express is that – although it makes sense that software development initially be lumped with other engineering disciplines, since it essentially emerged in it's modern form from electrical and electronic engineering – the perception of engineering as the final resting place of software development as a discipline is not right. Software development is bigger than that, and I want to talk about that here…
Software is as-if-not-more malleable than any other living thing or artwork. And – unless you somehow take into account the mass and velocity of the electrons involved – software is not realised through any specific physical structure. It manifests itself as patterns of electronic signals, through which data flows and is transformed. Ultimately, physical activity always results from and/or produces data that is fed into software, but the software itself is purely electronic.
Here’s Fred Brook’s (author of "The Mythical Man Month") take on programming:
“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures...”
One of the factors that makes it difficult for the idea of software development to grow beyond the engineering analogy is that working software is hosted by and dependent on physical structure – i.e. hardware. The development and arrangement of hardware naturally runs on far longer cycles than that of software and therefore certainly fits the classical engineering model.
Another factor that I would suggest keeps software development closely linked to engineering is the perception that from a business perspective, art is perhaps not seen as being as serious-of-a matter or as predictable or rigorous as engineering. Software is ever-increasingly important to business; in-fact, much of the world’s modern business process – from the smallest scale through to the very largest – is no longer capable of operating without software (think point-of-sale systems, telecommunications, share-markets and stock-exchanges). The idea that business is heavily dependent on (the result of) a largely artistic process (software development) though would probably make a good percentage of executives feel ill. So maybe from a business perspective, software development’s happy place is engineering.
[Repeat after me "Everything seems to be in ooorderrr" - source: https://www.youtube.com/watch?v=bhuOIbg-hM0]
Furthermore, for reasons that perhaps justify another blog post – it seems to me that art and engineering are in-fact inextricably linked. All of engineering, from a Mars rover to stone footsteps laid across a stream, could be seen to be forms of installation artwork; each subsequent piece incrementally extending the ideas of its predecessors. And art-for-art’s-sake is apparently a necessity – artistic expression is as old as human history – so it becomes a chicken-and-egg question; which came first, art or engineering?
[40,000+ year old cave art - source: http://news.nationalgeographic.com/news/2012/06/120614-neanderthal-cave-paintings-spain-science-pike/]
So I have come to think that art and engineering have a symbiotic relationship. And I think that software development more than (almost?) any other discrete discipline to emerge from history to-date, straddles art and engineering most evenly. One of the ways that technology emerges is when we figure out how to effectively commoditise an art form. That process of commoditisation is still active with software and is perhaps only just beginning.