Compsoft Flexible Specialists

Compsoft plc

Compsoft Weblog Compsoft Website News Archive Privacy Policy Contact Us  

Saturday, November 13, 2010

Øredev 2010 - Day 5 - Tristan Smith

Ten Big Holes - Software for the Next 20 years - Nolan Bushell (Founder of Atari)

Nolan covered some really interesting futures such as Auto Cars, a future without credentials, nanobots, augmented realities and swarms.

My last 30 failures and what I've learned so far - Ted Valentin

Ted Valentin gave us a decent talk covering his path into software development and covering some of the lessons he'd learned.
He talked about how success and failure are both parts of the same coin.
He cited some indy successes with Plenty of Fish, Million dollar homepage and Chat Roulette.
The success criteria he covered:
  • It should be quick and easy to build,
Make use of Facebook login, Twitter integration, Flickr images, RSS, APIs and open data to make it easy to buiild.
  • Simple to maintain
  • Easy to make money
Using Google Adsense, Affiliates (Plenty of Fish, Tradedoubler), Freemium, Selling (other peoples) things, Partners, Sell the site.
  • Easy to get visitors
Use Google, make your site good link bait, use good keywords, give it a long tail, prefer low keyword competition, aim for low bounce rates. Make use of Google Trends to find the right keywords, Social networks, Piggybacking on popular services, Returning visitors (email), Blog widgets, iPhone, Referrals, PR
  • Fills a need
He gave some examples where not following these resulted in fails:
  • Making a site focussed on an unsearched for keyword.
  • Making it too hard for visitors (making them work when they reach your site) leads to high bounce rate.
  • Not making the site monetisable leads to less investment. Geographic site for used books, not needed.
  • Not having a deadline, either GTD throw it out or set a launch party to get social pressure to make you do it.
The bottom line was that It's fine to fail, it's better to fail fast and cheap.

97 Things Every Programmer Should Know - Kevlin Henley

An open source crowd sourced compilation of collective wisdom from the Experts. Why 97? Strong prime? nope, because it's not quite 100, it's not trying too hard.
Deliberate practice to master the task, not complete the task(Katas) - Jon Jagger
Estimates negotiated to Targets which is made into a commitment - a promise to deliver specific functionality to a certain level of quality by a certain date.
Kevlin only managed to cover a few of the points in the book, well worth getting.

Social Media and Personal Branding as Project Leadership Tools - Dave Prior

In 15 words or less, describe your brand.
What does this say about your promise of value?
Think about your persona - the mask you wear to portray a definite impression and conceal your true nature.
Putin is a good example of this, holiday photos all show a beefy masculine character, showing strength.
Define your brand that will enable you to stand out and make sure that you can live up to it. Be consistent with it or people will lose trust in it.
Sender Receiver Model
Sender > Encoding > Message - Noise - (Encoding can be a bad mood making your message change)
How are you encoding the message of your brand?
Be interested and be interesting, this is key to social media.
4 types of social media users
1. Carefree / Careless (detracts from your brand if you say inane things)
2. Noise Makers (Look at me)
3. Barkers (Associative or braggers - Not engaging)
4. Strategic / Tactical users
Your digital footprint is your new permanent record. You have to consider this when you're posting online. Would I want anyone to be able to see this in 10 years? Make sure it's something you can wear, use and maintain without being excessively protective about it.
Social Tokens - The Fawn Liebowitz Experiment - Using core references to find people on the same wavelength to skip straight to trust. Something people have an emotional tie to. Eases communication flow, establishing more than just a common interest, forms a deeper bond by finding joined ownership to tribes.
There's no award for volume, in fact too much can dull your message.

The 9 Reasons you're not apprenticing anyone - Dave Hoover

"Today we have more developers than needed, but we have a shortage of good developers". Pete McBreen
  1. Your company won't let you Your company can't stop you, it doesn't have to be a full apprenticeship 'program'. It could just be grabbing lunch together.
  2. You don't like your job Change your job or change jobs, work on it, introduce change, challenge people.
  3. You're too busy You've got things to take care of before you can build in time for apprenticeship. Take control!
  4. You're a road warrior Leave assignments, just because it's not ideal doesn't stop it being possible.
  5. You're independent Feels like way too much responsibility. Contract with options to hire and defined milestones makes it easier in this case. Leave a legacy.
  6. You're not good enough Yes you are, you don't need to be the ultimate master of a subject to get started down the path.
  7. You can't find any apprentices Keep looking! Check the user groups they're full of passionate people.
  8. You don't like to mentor  Even if you don't want to do it yourself, try to be gentle, don't stop others from trying.
  9. You don't believe in it. (Gave some examples where it really worked)
Start small, incrementally, do retrospectives.
Pair programming, pet projects with milestones and code reviews

True Tales of the App Store Making iPhone Apps for profit - Jack Nutting

Some points form his talk:
Cheaper apps attract more haters.
Reducing price can often decrease ratings.
The structure of the App store means it's a hit driven economy, you can see flocking behaviour as a result.
Apple has a number of methods of raising the focus on an app (Staff Picks, Themes etc).
Ways of making money
In app purchases, lite versions, iAds + competitors.
Build free apps that help people use your own business.
Gameify dull activities.

If you're going to be a copy cat, add something extra.
People love stories, no matter how stupid, work them into your games.
Updates can increase popularity and increase value (Doodle Bug, Pocket God)
Eliminate Choice - Make your app as simple as possible but not simpler - modified Einstein quote.

Market while coding, find enthusiasts and give them sneak peaks.
Work your social networks.
Issue a press release.

Øredev Conclusions

Having attended Tech Ed in previous years due to our focus on .NET technologies, we've changed our focus more towards mobile development in general. This means we've hit Android, BlackBerry, iPhone and Windows Phone 7.
Øredev has up to 8 tracks going on simultaneously with tracks from below:
Java | .NET | Smart Phones | Patterns | Social Media | Agile | Software Craftmanship | Xtra (non coding related extras) | Architecture | Cloud & Nosql | Realizing Business Ideas
The sheer amount of options is quite daunting at first but it really does expose you toa lot of useful content that you just wouldn't find at a domain / technology focussed conference.
One of the biggest takeaways for us has been around process.
Working across so many different technologies and projects at the same time has an overhead in management, one that we've managed so far using Scrum. Scrum's a great methodology but it isn't quite as flexible as we sometimes need it to be, in Scrum you'd choose a number of tasks from the backlog for a sprint and not deviate from it. We do sometimes have emergency work and rush jobs that can't wait until the next sprint. This can be a real pain when you have to keep half heartedly adopting a methodology.
Kanban is a more flexible methodology that both Tim and I have mentioned in the blog so far, we saw a lot of sessions on it. We're both convinced it has the right managerial qualities as well as psychological benefits to suit us really well.
I really hope you've enjoyed hearing about the sessions we've been to, Øredev is a great conference one I can wholeheartedly recommend. Bring on Øredev 2011!

Øredev 2010 - Day 4 - Tristan Smith

Patterns of Parallel Programming - Ade Miller (MS Patterns and Programming)

We've reached the end of the free lunch, processing power and other computing metrics have stopped following Moores law, more cores are being added but they're not actually faster, there are just more of them.
This makes parallel programming all the more important, as we add more cores that serial programming just leaves unused. This makes the work Microsoft have done to make parallel programming easier with the Task Parallel Library (TPL) in .NET 4.
Ade illustrated the problem with a Stock market analysis program.
He pointed out that there are a number of things that block parallelism in your code.
You have to consider IO read/write constraints, actions that have fixed dependencies that impose a required order, that you're targetting items that take most time.
The TPL gives you Factory.StartNew, ContinueWith (To pass data from another task), ContinueWhenAll lets you specify a number of other tasks, ParallelFor lets you iterate in parallel (though you lose the index).
Think about Tasks vs Data, Control Flow, Control and Data Flow
When dividing up parallelisable tasks the size of the data chunks has issues where if you make it too big you underutilise whereas too small you thrash.
Using the ThreadPool is making use of the scheduler that focuses on making use of the available resources, the TPL uses a scheduler itself as seen with ContueWhen.
It's important to check that the tasks taking the time are the ones you're targeting to parallelise. Making sure there's business value that's focussed on, don't do it for the sake of it.
With Parallel.For because you can't do index incrementing parallel code, you have to factor that into the code you run.
Calculating totals for example requires an overloaded Parallel.For where each method calculates a subtotal and the grand total is calculated afterwards with a lock on the value being added to.
Parallel tasks can't really use shared state, you get locking issues so when shariing state, if possible don't share at all, use read only data, synchronise afterwards.
You can consider running parallel tasks to see which the fastest result to come back, then using Cancel and Task.WaitAll to cancel the other running tasks.
BlockingCollection - Reading in a file line by line, adding the lines to the blocking collection such that the processing of each item can be parallel where the collection can't be.
Don't just rewrite your loops, figure out what your users want and what's actually taking the time.
Architect for Parallelism.

In the clouds with the RX framework - Glenn Block

We're increasingly designing our systems to accommodate latency which is an increasing trend now our code is running in the cloud. RX is a handy tool for this..
RX is a library for composing asynchronous and event-based programs using observable collections. Systems where data is constantly coming in and it needs to be reacted to.
You can do this already, but this is currently really hard. We tend to work with collections in a pull based model, iterating - give me the next, which is blocking. This can mean locked programs that become non responsive.
The key interfaces to make use of it are IObservable + IObserver which give you Subscribe and OnNext, OnError, OnComplete meaning you're reacting to, not controlling the flow.
It's reactive rather than interactive.
Perception is reality, users faced with hangs and slow updating data, believe that's what the app is.
You need to be aware that if you're not using a true observable , you're not going to see the asynchronous behaviour. For example Enumerable.Range(0, 3).ToObservable() would be running synchronously.
RX is available in WPF, Silverlight Toolkit and WP7.
You can choose what thread to observe on, for example observing a textbox keyup event.
Throttling by time, filtering of which events to observe. Google Translate example.
They're working on new Async features that work with the RX framework and interestingly LINQ to Objects in JavaScript..

ASP.NET MVC 3 - Brad Wilson

A whistle stop tour of the new features of MVC3. New pluggable view engines like Razor, HTML 5 default templates, integration with jQuery validate, Nuget (automatic installation and dependency filling), DI and IOC injection hooks, global filters and more granular request validation (so individual properties can be marked as ValidateInput(false) to allow HTML content through) and a bunch more.
A search for MVC 3 will give the same info as I would, so I won't enumerate the features in any detail here. There will certainly be some useful additions to our processes though.

Twitter's Real-Time Architecture

An unfortunate choice for me, the speaker Kyle Maxwell was fighting his nerves the whole way through which made it quite excruciating to watch (and frankly dull).
He talked about briefly and somewhat incoherently about various sub systems they use, a queuing system, daemons used to spray messages to data shards. The different parts seem to be composed of entirely different languages (scala, ruby and some others I'd never heard of).
All together a disappointing session, I'd hoped to get some takeaways from it and didn't take anything away.

Kanban and Scrum - making the most of both

Henrik made a bunch of points which are covered in the free book he released [Insert url for PDF] (It requires registration but nothing more). As a result, I'll just describe one example he used to show how limiting work in progress is a productivity win.
After getting a volunteer from the audience, time how long it took to write a name (4 seconds), he asked for 4 more people to come up on stage.
He then asked for a time estimate for writing the 4 names, (20 seconds).
With that he put the obstacle of not limiting work in progress, all the names had to be written one letter at a time. It took almost 2 minutes! As a German being told Swedish names this added to the time taken.
This was a somewhat contrived example but still illustrates that context switching and working with unlimited work in progress can be a real issue.
Scale that up to normal jobs where in a single day you have to context switch 3/4 times a day and you can see that this example bears out in real life.

Øredev 2010 - Day 5 - Tim Jeanes


Omg omg omg! It's Nolan Bushnell, the founder of Atari!

Session 1 - The Technical Debt Trap - Michael "Doc" Norton

The term technical debt refers to problems or bad code that you decide you'll fix later but never really do. A little debt early on speeds development. It's fine so long as you pay the debt back soon, but left unattended is like accumulating interest on that debt as the bad code compounds.

Though developers generally hate technical debt in any form, it can be a good thing provided it's managed correctly. It allows for rapid delivery to elicit quick feedback and correct the design.

This isn't an excuse to write code poorly now: if it's debt, you intend to pay it back. You can only do this if you write the code in a way that you can refactor it into a better shape later on. Dirty code is to technical debt as the pawn broker is to financial debt.

If you don't have a plan to get out of the debt you're in, you don't have technical debt, you just have a mess; cruft.

Much technical debt can be avoided; however, much is unintentional. When you look back at your old code you find it full of cruft that needs cleaning up. Unfortunately, how you got into debt doesn't excuse you paying it back.

A lot of handling technical debt comes down to handling expectations. We know we're going to incur it, so we need to balance that against the pressure for speed over quality. Technical debt then compounds as mess is added to mess in order to maintain velocity. Adding clean-up sprints to the dev cycle generally doesn't work. Studies show that the cruft just re-accumulates rapidly afterwards. A better pattern is to clean continuously: try to leave the code cleaner than you found it.

Session 2 - C#'s Greatest Mistakes - Jon Skeet

We love C#, so it's great to hear such an expert on the subject (and someone who loves it even more passionately) talking about what's wrong with it.

This was almost entirely a code-based session, so it's hard to write about without duplicating reams of code.

Ah well.

Session 3 - Fostering Software Craftsmanship - Cory Foy

We saw a few case studies of people who have opted out of the traditional software development career structure to follow instead a more journeyman-type model whereby they spend their time travelling and pairing with people and exchanging ideas.

Historically, software development became increasingly prescriptive from the 1960s onwards. The Agile Manifesto was a massive backlash against this that reoriented programmers' values much more towards being flexible and adaptive. Though the older models were more heavyweight, they did lead to stricter practices.

Empowerment can be defined as sharing information with everyone, creating autonomy through boundaries, and replacing the old hierarchy with self-managed teams.Agile practices often fail when management still works from a carrot-and-stick way of rewarding goals or punishing failures. If we're to work as a team, individual rewards and bonuses are always counter-productive.

Session 4 - Real Options - Olav Maassen

Similar to buying stock options - by purchasing an option now to buy later at a price set now - almost everything can be considered an option by weighing up the benefit against the loss incurred by choosing against the option, whether than cost/ benefit is financial, emotional or moral.

Options have value; options expire; never commit early unless you know why.

Similarly, buying a plane ticket far in advance is much cheaper than buying it at the last moment. The earlier ticket is non-refundable, but the flight is not mandatory: all you've bought is the option to fly then. If you choose not to take the option, you've not lost much.

Being uncertain can often be better than being wrong.

In agile practices, pair programming provides options: two people think of different ways of tackling the same problem.

Scrum backlog provides options: every idea is there. Action is postponed until the time the priority decision needs to be made.

Session 5 - True Tales of the App Store - Making iPhone Apps for (Fun and) Profit - Jack Nutting

Developing apps for any platform's app store let's you skip most of the hard work of selling software - you have no inventory management, payment handling or shipping. However, this has led to a crowded market, so marketing becomes a bigger priority. You can basically run your own software firm from your desk, but marketing isn't something developers normally do that well.

The app store has changed the public's relationship to software - they buy and discard software much more freely now, many of them for the first time.

The lower the price of your app, the more downloads you'll get, but also the more haters you'll get - more low ratings and more negative comments.

The app store is a hit-driven economy: the better you're doing, the better you continue to do. If you're outside the top fifty or so, you can sink without trace. If there were ever a bug in the app store that showed a non-entity app as number one, within a day it would probably actually be number one.

Releasing a "lite" version of your app can help to gain publicity, but Apple have strict rules against non-functional buttons that only tell the user to buy the full version to activate that feature.

Other than making money directly through the app store, advertising can be a revenue stream, but it's generally a slow one. For games, in-game purchasing of additional levels can a;also work.

An alternative is to build free apps that help people use your business: the app doesn't make any money in itself, but acts as direct or indirect advertising to the existing business model.

Before you even write a line of code, be smart: don't reinvent the wheel. Or if you must, at least add something new.

Making an app that people will keep using, then even if they don't spend any more money in it, it lengthens its word-of-mouth viral capacity. People love stories - even (or perhaps especially) stupid ones. This gives you the excuse to continue to add new content. You can add variety by adding mini games (even in games).

Make your app as simple as possible, but not simpler. Unless it's a game or a book, people will want to be in and out of your app as quickly as possible. Eliminate settings wherever possible; if you can make a choice on behalf of your users, do so.

Thursday, November 11, 2010

Øredev 2010 - Day 4 - Tim Jeanes

Session 1 - Patterns of Parallel Programming - Ade Miller

[The source code from this session is available at:]

With massively multi-processor PCs becoming increasingly mainstream, it's important to utilise the full scope of processing power available wherever possible. .NET 4 implements a bunch of features to make this relatively painless. Unless we take advantage of parallelism, our software may actually run more slowly as newer machines have more, slower cores, rather than a faster single one.

We saw the Visual Studio 2010 profiler. This is baked into VS2010 and shows clearly where the CPU is being used, together with disk access, etc, on a timeline. This looks really handy for identifying where the bottlenecks really lie. Using profiling is critical - understanding the application and where the problems are first is vital, rather than just wildly parallelising unnecessarily.

There are a couple of models for parallelism: one is task-based parallelism where we consider what tasks need to be done and run them in parallel. The other is data parallelism: for example in image processing you could split the image into pieces, process them in parallel and then stitch them together in the end.

In data parallelism, it's important to get the data chunk size right: too big and you're under-utilised; too small and you waste too much time thrashing.

You also have to take into account at runtime what degree of parallelism is appropriate: your software may end up running on a machine in a few years that has far more processors than were available when you wrote the software.

Rather than counting processors yourself and manually creating threads, it's better if we can hand this responsibility to the .NET framework and allow it to take care of the degree of parallelism itself. Ideally we just express where parallelism can take place.

In .NET we can do this using the Task<> class. We specify a task that needs to be performed, but we don't say when it starts. We only request a result from it. You can specify dependencies between tasks.

There are a couple of standard patterns that are addressed for data parallelism: loops where items can be handled independently; and loops were the required result is some kind of aggregation of all items in the set.

The first of these is trivial: replace for() with Parallel.For() and you're done. Bear in mind though that you can never assume that the items will be processed in any kind of order at all. Parallel.ForEach can even be used on collections where you don't know the collection size up front.

There's also an overload of Parallel.For that allows for data aggregation between threads. The only gotcha is to ensure you do your own locking in the step that combined the sub-aggregations from each parallel section. Locks are pretty bad in terms of performance though, so if you find you're getting a lot of them in your parallel tasks, it's a good idea to consider whether or not this is the right way to go.

this isn't a silver bullet: parallelism is still hell if your tasks need to share data or need to do a lot of synchronisation.

Task.WaitAll allows you to wait until all parallel tasks have completed; Task.WaitAny allows you to continue after just one has finished. Tasks can be cancelled if they're no longer needed. These last two can be combined if you're doing a parallel search for a single item in a large set.

The Pipeline pattern can be used where many tasks have to be performed on data items that are idenpendent of one another. I.e. once Task A has finished with a data item, it can immediately be passed to Task B. Buffers exist between the tasks that can have size limits on them to ensure that processing capacity is used most where you need it. This can prevent thrashing and memory overflows.

In some cases it's appropriate to combine parallel strategies: if you pipeline has a bottleneck, that stage can itself be parallelised (much like adding more worker to the slow step of a production line).

Session 2 - Run!

Billed as a 5km run, it was mercifully a little shorter than that. Man, running along the Swedish coast in November is cold!


What was I thinking?

Session 3 - Personal Kanban - Jim Benson

Building a personal kanban board for your own work (or even for your own dreams) can build a lot of clarity in your own mind. It removes the brain clutter than creates stress and dissatisfaction, giving clarity to your current position and how well you're doing at whatever it is you do.

Even in a work-related personal kanban, it's worth including non-work items. The fact that you're worried about a sick relative is a distraction to you today, so it belongs in your WIP column as it's a distraction to you that's impacting on your performance.

We tend to want to take on way more work than we can deal with, because we want to be productive - or at least be seen to be. We often don't recognise that we have our own WIP limit, that when exceeded, dramatically impacts on our productiveness.

Kanban can also be used for meetings: It makes for a more flexible, dynamic agenda that contains things the attendee actually want to talk about. it also helps to keep the conversation focussed. I'm not totally convinced on this though - it's hard to say for sure when a discussion on a topic is definitely "done".

Session 4 - MongoDB - Mathias Stearn

MongoDB is a document-orientated noSQL database. A document is essentially a JSON object, which gives a few advantages over a traditional SQL-based database.

As the data isn't stored in defined tables, all objects can be expanded dynamically. Also, as relationships aren't used except where needed, parent and child objects can be held as a single object.

For example, if you're storing a blog in a database, you'd hold each post as a document. That would include all tags and comments as array properties on the blog post object. Physically, these are all held in a single location on disk (effectively as a binary representation of the JSON string) making object retrieval very fast. Data writes are also fast. This makes MongoDB appropriate for high-traffic web apps, realtime analytics or high-speed data logging.

Querying the data is function-based rather than SQL based, but this really only leads to a syntax difference: db.places.find({zip:10011, tags:"business"}).limit(10); is an example query equivalent. Pretty self-explanatory, and a little shorter than SQL. Critically though, there's been no join between a Business table and a Tag table that you'd get with SQL.

More complex queries are also possible, such as {latlog:{$near:[40,70]}}.

Data can be indexed by property to improve performance.

Updates to records are achieved by combining criteria to find the relevant document, with a $push command that adds or updates properties on the document.

Where appropriate, objects needed be combined into single documents. Joins can be achieved by adding ObjectId references as properties on documents. There's no such thing as referential integrity in this case though.

Actions on a single document can be chained together and will be treated atomically, giving you a rough equivalent to SQL transactions. There's no such thing as atomic operations across multiple collections.

MongoDB is impressively mature in terms of deployment features such as replication and database sharding.

Session 5 - Challenging Requirements - Gojko Adzic

Customers often ask you to implement their solution to a problem. This often leads to nightmare projects that are way bigger than they need to be. It's generally better to understand what the real problem is and solve that. The implementation of the true solution can well be better than implementing the solution the customer initially identified.

Similarly refuse to use the technology the customer specifies unless you first confirm that the technology actually matches their need. Often they'll think they know the best way to implement a solution, but another option may be far simpler and more appropriate.

Don't rush into solving the first problem they give you; keep asking "why" until you get to the money: that'll be their real requirement.

Know your stakeholders: who is going to use this and why?

Don't start with stories. Start with a very high level example of how people will use the system and push back to the business goals. The story you're presented with may well not be a realistic one.

Great products come not from following the spec; they come from understanding the real problem and whose problem it is.

Effect maps can be used to trace the purpose of all features. They ask why the feature is needed, who the people are that want the feature, then what the target group want to do and how the product should be designed to fulfil that.

Session 6 - Kanban and Scrum - making the most of both

OK, I think it's fair to say I'm officially totally in love with Kanban now. However, I'm also fairly fond of Scrum. Short of a Harry Hill solution to this dilemma, I attended this session to see how we could take the best of both worlds.

The key features of kanban is to limit the WIP at any stage, and to measure the flow (typically by measuring the lead time - the time it takes for a task to cross the board).

Having a lot of parallel tasks or projects running simultaneously leads to more task switching, which leads to more downtime and delays, which leads to all the projects being completed later.

Doing tasks in series, perhaps with a background task to work on while the main project is blocked, keeps everyone focused and more productive, completing projects sooner: leading to happier customers and happier developers.

There's and example of the evolution of a kanban board at

Scrum prescribes rules more than kanban does, such as planning and committing to sprints, regular releases and retrospectives. Some of these items can be useful to add to the basic kanban model, depending on what's appropriate for the company.

Kanban doesn't prescribe sprints (though they are allowed). I think we may well go without sprints, just because at Compsoft we need to be able to react much more quickly - it's often too hard to commit to a period of time during which our workload can't be altered.

Kanban focuses on having multi-ability teams, where team members frequently help out on tasks outside of their normal primary area of expertise. It's not that everyone has to do everything though (just as well - my Photoshop skills are pretty lacking.).

Estimation is flexible in kanban. Some don't estimate at all - just count; some estimate in t-shirt sizes (S, M, L), some in story points, some in man-hours.

Øredev 2010 - Day 3 - Tristan Smith

Keynote - Dr Jeffrey Norris - Mission Critical Agility

Having shared a naked leap into the ocean after a sauna with Jeff, then chatting to him over dinner we felt a special connection with him. He gave a fantastic keynote, covering three key parts of Agility.
Vision, Risk and Commitment
He illustrated vision by talking about Alexander Graham Bell, inventor of the telephone. The environment of the time was one of a total monopoly by Western Union with the Telegraphs. The problem with the technology was that it was single message only, WU had snapped up all the available inventors to work on a multiple message telegraph.
Into this came a wealthy benefactor wanting to break that monopoly by inventing the multi-message telegraph first, without access to a big pool of inventors he snapped up Bell. Bell, whose father had invented a method of teaching deaf people to speak wanted him to take up the family business. The benefactor had a deaf daughter who Alexander taught to speak (and got romantically involved with).
Despite the pressures he faced, he kept working on his vision with  it eventually resulting in huge success. Interestingly, Bell's research into the telephone was based on a mistranslated document, he had read that someone had successfully changed sound to electricity and based on that belief managed to find a solution. It turned out that no-one had done anything of the sort.
RISK was illustrated with the Moon landings, NASA were working on a couple of methods of getting to the moon. The popular option was just to have a huge rocket that flew there and flew back, simple! The alternative option was raised which involved building a 4 part rocket which would involve space walks and multiple separations in space. A much more complicated solution, a much riskier one and yet it was the one they went for, and successful too. Vision and Risk.
Factoid: While the rocket was on the ground, it was the largest building in Florida, then they launched it into space!
COMMITMENT While we're constantly reminded of the risk of change, there's also the risk of failing to change as shown by the Western Union example. Holding back critical investment until after evaluating multiple routes and holding back as long as possible can increase agility.
Failure on a followed route can lead to other routes that may be successful.
"Leave the beaten track occasionally and dive into the woods - Graham Bell.
I have not failed. I've just found 10,000 ways that won't work. - Thomas Edison.

Take Control of Your Development Career - Michael Norton

The key to Doc's talk was, figure out what you really love and take control!
If you follow the points below:
Get noticed, Get together, Get your Mojo on, Get Naked, Get schooled
Get Noticed
Learn your business so you're better able to solve problems, you can get better insights into other problems that can improve efficiencies too.
When you're looking to move on up, don't forget to DO your job. You need to be recognised as a good worker in your current role before being elevated to another you're focussed on getting.
Make yourself expendable (so you can be replaced in order to move up and out of your role).
Get Involved
Join a user group, they're a great place to encounter new ideas. If you help out with a user group or even start / run one you get much better visibility. You can then contact the types of people you'd never get a chance to other wise in sourcing speakers for your user group.
Get your mojo on
Improve yourself, get your Koans and Katas on, hone your craft. Build something non critical but important to you as a great way to learn in a non contrived way.
Get Naked
Run with people who are better than you, it's much easier to improve when you're the lowest in a group than the highest, otherwise it can lead to laxity.
Use something different for you (set up a CI box, learn a new language).
Admit when you don't know.
Get Schooled
Find a mentor, attend conferences, teach a new language or subject (your commitment is a great motivator to learn that new subject).
Finally, Get Started!

Tightening the feedback loop - Patrick Kua

Where as with software development TDD and Continuous Integration gives us instant feedback, feedback with people tends to be done on a longer timescale.
Personal reviews tend to be yearly. Yearly feedback makes it somewhat irrelevant, it needs to be done after significant events so that it can help avoid paths that shouldn't be taken and fix issues early.
Giving effective feedback should strengthen confidence or improve effectiveness feedback shouldn't be about you as a person and you shouldn't be thinking 'How does this help me at all?'
It's important to create a feeling of safety so the person is open minded to it. Give feedback in private, ask if it's the right time. Can I give you some feedback? Is now a good time?
A good feedback formula is - Specific time, observed behaviour, perceived impact, "Let's discuss", suggested solution. For example "Yesterday when pairing, you laughed at my solution, I felt belittled and upset."
Giving Feedback
Give feedback earlier, create safety, focus on behaviours, not too much, make it a conversation
Receiving feedback
Rule #1 Ask for Feedback
Rule #2 Don't be defensive
Rule #3 Seek clarifications
Rule #4 Say thanks (Positive reinforcement loop - drive culture of feedback)
Rule '#5 Take action (Not acting on feedback will lead to a lapsing of confidence in giving feedback at all)

Clarity means Completion: The Psychology of Kanban - Jim Benson

Kanban column headings called Value streams they're the steps you take to provide value.
Existential overflow - The capacity to work while stress increases.
Tasks that are left uncompleted leaves your brain spinning. This is called the Zeigarnik effect.
The less control you have over the flow of tasks, the greater this effect.
Seeing tasks flow across the board helps lessen the effect.
Metacognitiion is the layer which analyses how you learn and what impact that has..
Connect and Clarity
Pulling a backlog task onto the limited WIP makes that a valued task to the person pulling it. This can lead to thoughtful pulling where the impact of a given task is evaluated and prioritised. The investment can make that person's task's progress  more important and the fixing of issues that hold it up along the way more important.
In this way Kanban depersonalises the workflow, if there's a problem, it's not just Bill's fault it's personal investment in the processing of a task. The relationship to work changes this way.
The morning stand up which is scrum is often zombie like, where if you're lucky you tell everyone something they didn't know this can be transformed into a task based one where the focus is less on what you did and didn't do and more on where tasks are blocked.
Kanban works on a number of levels, one of which is that it rewards the brain in a number of ways.
The brain loves it when there's no blame, it loves collaboration and it loves pattern matching.
The context of work Todo / Done makes a value map. You can see the things that were valued by those done, people can take pride in the tasks done and it can increase respect.
Developers range from people with ADHD to Asbergers. Kanban changes from individual focus to flow. It makes it easier to spot a task taking a long time so where the Aspergers type is focussed on perfection you can see that immovable task.
The goal is to get tasks done and off the board.
There's a clear definition of done, if the post it is on the right and hasn't moved in a while.
Tasks with happy faces show nice tasks vs bad ones which can show the subjective mood at any time. Retrospectives - why did this suck, can we fix it?
There's a Kaizen impact (continuous improvement) due to the real time fixing of issues (sorting of problems found).
There's some Kinesthetic feedback too with the tactile feedback of moving post-its.
The moving of post-its has a parallel with child raising where picking a task and moving it through the different stages is like birth, growth, pain and release where each task is a plot point.

The developer who played with XAML - Jeff Wilcox

A pretty average session, added a few notes below but I mostly wrote up other notes in this session.
Silverlight 4 gets inline properties
Suggestion of dropping attributes onto new lines to make Source Control changes more obvious.
Avoid triggers (designers can't figure out triggers, VSM is a replacement for this)
Always do Static Resources over inline styling.
Putting curlies in strings requires "{}Hello {user}a".
Really bad error messages are as a result of a transition between managed and unmanaged code.
Dictionary improvements to xaml in SL 4 make it possible to create objects dictionary style in xaml.
obj > debug generated files are in there which can make it easier to debug issues.
Attached properties - Canvas.Left, Grid.Row where they only apply if relevant.

Agile Release Planning - James Shore

If you're not paying attention to the business success factors as well as the technological ones, you're going to fail.
Reality on the ground compared to the beautiful plan can be very different.
He used a real pre-planned holiday that went wrong for him with a partially planned holiday with flexible activities. There's a win for adaptability with late defined plans.
Minimum marketable features
The minimum deliverable marketable value.
Deliver value not technology, deliver the most valuable features first.
Releasing these features means you can start making money sooner.
Build an entire vertical slice at a time to allow the MMF to be built, not a 3 tier method of writing Data Layer, then Business Layer then UI.
Avoiding "The Grand Plan" and just working on feature incremental design and architecture means as you go you can change the direction for better paths, it makes you more agile. The idea being that you avoid "The Grand Plan" being twisted over time with new features and changes.
Working this way can also reduce waste.
Dividing the tasks into Vision, MMFs, Stories and Tasks gives you a range of time and ordering to the level of detail required at each point. This lets you plan in a more general way further out but more specifically closer in.

The Burning Man - David Prior

A session covering a number of the failed or dysfunctional projects David had worked on in his career.
As a reader of The Daily WTF I'd read stories about similar situations to the examples he gave, it's always useful to learn from mistakes so this was an interesting if somewhat incredulous talk at times.

He gave examples with multiple project owners fighting, half hearted scrum, PMs not passing on accurate progress reports such that the client believes everything is still on track. Teams of unqualified developers without any action being taken to rectify it. Backend systems handled by unreliable people with no progress updates and monitoring. Alcoholic employees who were geniuses when sober.
The cause he had found in almost all of these cases was fear. Fear of repercussion, fear of failure, fear of being fired.

The titular Burning man example was a disaster because the backend system his company was due to integrate with was being handled by the client's CTO. The CTO had just sold his stock for millions and taken his developers to the Burning Man festival 4600 miles away two weeks from the test date (and they wouldn't be coming back for 5 weeks). When David asked for the code, he found that for that entire year the CTO and his devs had 0 lines of code.

His solutions included daily introspectives and failure focussed brainstorming.
The failure excuse model can be identified by things such as "So. I can't [do this thing] because [obstacle] won't let me." and "I want to [do this thing] because [reasons] and I can't because [reason]".

Wednesday, November 10, 2010

Øredev 2010 - Day 3 - Tim Jeanes

Elk burger

Elk burger: this is made of win. And elk.

Session 1 - Keynote - Mission Critical Agility - Jeff Norris

The definition of mission criticality is when everything is on the line. For Jeff at NASA this may be the fate of a spacecraft; for more run-of-the-mill programmers it may be keeping a customer, preserving the life of the company, or keeping your own job. this makes it no less mission-critical.

Taking examples from sources as disparate as Alexander Graham Bell to the 1969 moon landings, Jeff outlined key elements of success in agility.

A key factor of agility is vision: the ability to see what's possible even when it isn't on the well-trodden path. Vision normally involves a lot of risk.

Though commitment seems a virtue, it can be best to remain as uncommitted as possible for as long as possible. Agile methodologies can allow you to remain flexible until remarkably late in the project lifecycle: by developing only as little as is necessary for each iteration of development, hard commitments to certain technologies or avenues can be postponed until absolutely necessary. Early commitment to a single decision is the antithesis of agility.

Session 2 - Deep Dive Into HTML5 - Giorgio Sardo

HTML5 is undoubtedly going to change the way we develop for the web, so although we won't be able to count on all our users having a browser that supports it for quite some time yet, it's critical for us to ensure we're right on top of it from the outset.

Giorgio's a Microsoft evangelist, and it's encouraging to see Microsoft on board with web standards.

Even though the HTML5 spec isn't totally complete yet, it's already becoming supported by some browsers - or at least the parts that are stably defined.

HTML makes for much cleaner markup. The DOCTYPE tag can be stripped right down to just <!DOCTYPE html>. It's no longer necessary even to have separate <head> and <body> elements (though they can still be used if you find it helps with clarity).

HTML5 adds a bunch of new tags that though they don't render any differently to <div>s, can help with the semantics of the page, which in turn helps with accessibility.

The new <video> tag makes embedding video a whole lot easier. The only required attribute is src. Defining the video file to display is literally all you need to do to put a video on your page. There are plenty of other attributes though, such as the image to show before playback begins or if it plays automatically. You can alter the playback speed of the video. You can specify numerous <source> child tags to offer various source files in different formats, in case the client's browser doesn't support the codec of your original file. The browser will play the first <source> that it can support. For fallback, you can specify an <object> tag for Flash or Silverlight after the last <source> tag: a browser that doesn't recognise <video> or <source> will ignore those tags but still pick up on the <object> tag (or some static apology that the user can't see the video). Adding an onerror attribute to the last <source> tag ensures that HTML5-enabled browsers will also use the <object> if none of the video sources are supported. Disappointingly there's no fullscreen mode, for security reasons. All attributes are accessible and alterable via javascript, including the position of the video playback. It's also possible in javascript to detect whether or not the browser supports the <video> tag at all, or if it supports certain video codecs (though the HTML5 spec says these functions return such values as "maybe" or "probably").

The <canvas> tag is another major addition to HTML. This allows you to draw vector graphics on the page. <canvas> support can easily be detected in javascript. The canvas.toDataUrl method can be used to export the content of the canvas to a single static image. It's important to ensure the canvas has loaded before you attempt to draw on it dynamically in javascript: draw instructions made before that will be ignored. For animations you have access to the refresh frame rate of the browser. These vary between browsers and how busy the machine is, so time-based animations are generally the better way to go (though also syncing with the browser refresh makes for smooth animations with less CPU overhead). You can also draw videos on the canvas, and add matrix transformations to how the video is displayed.

HTML5 supports svg both as inline <svg> tags in the browser, and also as a source file for an image. This means you can use svg graphics for background images, etc., resulting in much lower bandwidth than you would have using a large jpeg image. SVG images can also be created dynamically in javascript and then serialized and used as source to image tags.

We touched briefly on some new features of CSS3. An interesting one was the ability to define different styles based on the size of a screen - enabling you to swap image when the browser is small, or changing the layout altogether for mobile browsers.

Session 3 - HTML5 APIs - Robert Nyman

We recapped some features of video from the previous session. Another nice feature that the BBC are experimenting with is the implementation of subtitles. These can be held in <div>s on the page (and are thus indexable by search engines; then they are shown accordingly in javascript by polling the playback position of the video.

The Raphael Javascript library is a handy tool that makes building SVG graphics dynamically a whole lot easier.

There's a tension between using SVG or canvas as on the surface they offer similar functionality. The key difference is that SVG is always vector graphics whilst canvas is always bitmap-based. SVG is often more appropriate for generating dynamic images, whilst canvas is faster and more responsive for animations and games.

Web storage goes way beyond the capabilities of cookies. Cookies are extremely limited on size (around 4KB), whilst web storage give you 5-10MB, depending on the browser. The two types are sessionstorage that disappears when the browser is closed, and localstorage.that persists between sessions. These work as key-value pairs of strings, but JSON is a handy way of serialising objects.

There's currently a fight between WebSQL and IndexedDB. WebSQL is backed by Apple, so will probably be in Safari only. IndexedDB will probably be available in all other browsers (and hopefully in Safari too).

The Worker javascript object allows multithreading. It's initialised with a javascript file and can be communicated with from the main UI thread.

New javascript property is available to check if the browser is currently online, allowing you to alter the behaviour of your web application accordingly.

There's a drag and drop module in the HTML5 specification, but it looks like it's not going too well. If they can get it sorted out, it could be pretty useful - elements can be marked as draggable or as drop targets by use of attributes. It'll be interesting to see if and how this will be implemented on touch screen devices where  a drag action needs to be distinguished from a scroll - parts of flickr are already unusable on my phone.

The drag and drop API can be combined with the file API that allows you to drag files from the client file system to the browser, and provide you with metadata about the file as well as access to the byte contents of the file. This can be inspected in javascript, and then the file contents posted to the server asynchronously. Streamed upload, multipart upload and upload progress are all available in HTML5.

The window.history object allows you to push URLs into the browser history.

Data push from the server to the browser can now be achieved with the WebSocket object. Connections can be specifically opened and closed in javascript, and events are raised when data is received from the server. web-socket-js and SocketIO allow similar functionality in non-HTML5 browsers, if you need backwards compatibility.

More at

Session 4 - Clarity Means Completion: The Psychology of Kanban - Jim Benson

Existential overhead - the things that stress your team out: all the things that take up brain space and prevent you from working. We find we get this when there's a lot of work backed up that needs doing, or that is work is progress. Being able to push things to a place called "done" frees up space in your brain to focus on the things you should be working on now. Typically developers love to start new things and often don't finish them and flush them from their minds. Kanban keeps the loop tight, ensuring you're only thinking about the things that matter right now.

Flow- being able to see the whole flow of work in the project. Though you know what you have to be caring about right now, all other tasks are visible, making it easy to push back on panic rush jobs: though you can still take them on, the fact that another task (that up till now was the most important task on the board) will be pushed down to lower priority.

Depersonalisation - The goal of everyone in kanban is to get a task off the right hand side of the board; not just to move it out of your column. It encourages co-operation between developers and testers, as developers can see when the test work queue is backing up. The fault probably isn't with the tester: with dev help they can most likely catch up with their workload. The whole team is focused on removing blockages.

Pattern recognition - Human brains (especially those in the IT industry) just love pattern matching. Kanban makes spotting problems and issues with your workflow a case of pattern matching: the visibility of the workflow leaves problems with nowhere to hide.

Learning styles - People with different learning styles tend to work in different ways: in the extreme, some will flit from the exciting part of one task to the exciting part of another; others will focus intently on one task until it's beyond perfect. Kanban keeps the balance: the goal is always to move tasks to "done" and never see them again.

Subjective well-being - It can be useful to flag tasks as being tasks you like and tasks you hate. In retrospectives, discussing what it is that makes tasks suck can lead you to realise what's causing pain in your overall processes and thus what it is you can do about it.

Session 5 - The Counterintuitive Web - Ian Robinson

This session wasn't quite what I expected: it turned out to be part of a series on RESTful practices that I wasn't all that interested in. Ah well, a few things were slightly interesting.

In a traditional web application or service oriented architecture, the server would keep track of the state of the interaction with the client - for example the position in the state machine that a customer has reached (requested order, ordered goods, paid, cancelled, etc).

In a RESTful application, we break the process into resources (quote, order, item) with verbs (GET, PUT, POST, DELETE), then specify operations (CreateQuote, SearchOrders, ReserveItem, etc) that are executed on the server in response to these verbs. Each resource then maintains its own mini state machine.

For an application to be able to evolve, we need at least one degree of freedom in our architecture: either we can continually add new verbs (as we would in an SOA), or new resources (as we would in a RESTful application.

Session 6 - Introduction to Core Animation - Marcus Zarra

Core Animation is one of the core technologies for iPhone and iPad development. It allows for animating 2D planes (or layers) in 3D space. It almost (but not quite) achieves the same as OpenGL. For most animation requirements, however, it performs slightly better than you could manage using raw OpenGL yourself.

It supports basic animation (to change a value from A to B, and keyframe animation to allow for many points which are animated between

The following can be animated: opacity, colour (including alpha), size and position. You can also animate matrix transforms. The API allows easier access to matrix transforms by exposing methods to animate rotation, translation and scaling on any axis.

Animation is best used to indicate user interaction, to give feedback to the user (for example to let them know something can be interacted with). It's also handy for simpler games. It's also very useful for highlighting alerts.

Several animations are provided for free, such as flipping the screen around on the y-axis, sliding on screen on top of another, etc. Custom animations can be created as well.

Unless you specify otherwise, the built-in animations take 250ms - long enough for the user to notice, but without them feeling like they're being held up at all.

Animations can be expensive, particularly if you're animating complex structures, or if you have layers with alpha transparency. The key is to measure performance with instrumentation rather than judging it by eye. Sometimes when you have bad performance you just have to experiment by removing features one by one to see what's actually causing the performance hit. Rounded corners, for example, are surprisingly heavy-duty.

Core Animation does most of its hard work (preparing the animation and working through the maths) on a background thread - only the actual drawing takes place on the UI thread. In later versions of iOS, even some of the drawing takes place on the background thread.

Session 7 - CSS3: Now and the Future - Jonathan Snook

The CSS3 spec is at the Candidate Recommendation stage, where it's unlikely to change much but isn't actually finalised yet. However, many browsers already support many of the features - often even features that aren't at the CR stage yet.

Some of the hotter new features are the new selectors (such as :nth-child), multiple backgrounds, border-radius, gradients, shadows, rgba colour definitions (allowing alpha on different part of an element such as the border and background), 2D and 3D transforms, transitions, multi-column support, and animations.

Safari, Firefox, Opera and IE9 support most of these features.

Multiple backgrounds look awesome and we've needed them for a long time. You get to specify as many as you like and they get layered one on top of each other. The unfortunate drawback is that there's no way to override just a single layer (for example in the rollover class for a button).

Many of the features now becoming available in CSS3 have been available for some time in various forms in older browsers. It makes the CSS pretty messy, having to include the correct CSS3 definition, along with the definitions for Mozilla, webkit and IE's proprietary legacy implementations. is a handy resource to check which features are currently supported in various browsers. detects browser support for various features and substitutes workarounds where they're not available.

Tuesday, November 09, 2010

Øredev 2010 - Day 2 - Tristan Smith

Koana, Katas, oh my!
(Corey Foy)
Corey started with a discussion of the differences between professional Software Development and other professional careers, pointing out that other critical jobs such as Doctors and Firemen don't do their learning on the job.
His point, while acknowledging that not all software is life critical, but certainly the cost to a developer of major failure with a new technology implementation on a project for example could be the loss of their job, a pretty critical issue for them.
The differences between Koans (a focussed learning exercise) and Katas (honing skills to problems with known solutions) were expounded with illustrations from martial arts. Shu Ha Ri learning was also talked about where Shu is learning by example, following steps thoughtlessly to learn a new thing. Ha learning is where analysis of the subject, why am I doing this, what if I do it an alternate way and Ri learning where the subject is instinctive. In martial arts, this would be where you know the katas and karate moves so innately that you could automatically defend yourself for example.
Other than the knowledge drop, the majority of the time was spent working on some katas where we in pairs solved solutions such as Fizzbuzz and Conway's Game of Life using Test Driven Development. Deleting our code after each iteration and starting again from scratch each time.
Interesting too was that the room had maybe 15 people in it from all language backgrounds and yet everyone managed to work together and storm through the problems.
A practical introduction to Kanban
Kanban is a Japanese methodology for process improvement and control.
It originated in the Toyota Manufacturing Factories after research into the Supermarket model of demand controlling the rate of production.
Kanban has some key principles:
  • Limit the work in progress.
  • Stop starting (new work), start finishing. (Using a queue where only one task is taken when the previous task is done.
  • Visualise the flow of work so that bottlenecks and other issues are easy to see.
After a brief overview, came the guys initiated a dot game where 8 people were divided up by job role. A post it note on the table had a dot based design and different coloured dots were given to the different roles. Business Analyst, Designer, Developers, Tester, Project manager and Customer.
In the first iteration the process was defined, each person would do a batch of 6 instances of their job (putting their coloured dot on the post it) before passing the batch to the next person.
What quickly became clear was that there were bottle necks and dependencies that led to undue pressure felt by people, some people were kicking their heels while others were slaving away. When the first batch was complete, the customer rejected all the work.
None of the team ever asked for feedback from the customer, everyone had their own interpretation of the spec and the feedback loop was too long as there was no feedback until the entire batch was complete.
Two more iterations of the exercise allowed changes to be discussed which brought customer feedback into the process and more individual informed involvement.'
It was a good way of highlighting some of the key strengths of Kanban, the problems experienced in the first instance where caused by too many items being processed, inefficiencies due to lack of visibility and slow response to those inefficiencies.
Some of the other points made along the way:
Context switching (limited by the 1 item at a time flow) tends to result in about a 20% loss in time per item, this has a major impact if you're repeatedly having to context switch. Some research they pointed at showed that context switching equates to a 10 point drop in IQ.
Work in progress also includes items that are complete but have not been released yet, or not been taken up by the next department (Dev > Testing > Customer Acceptance).
The higher visibility of problems means that bugs for example have a number of extra costs, there's the delay downstream for the time Testing takes, then the context switching tax of going back to a previous problem domain (and possibly project).
Catching issues earlier leads to a lower cost to change in requirements, making it easier for customer change requests to be processed.
Shorter lead times mean greater motivation, the higher perceived (and actual) productivity leading to a positive feedback loop.
Moving on to the Kanban board, tasks are added and prioritised with colours showing the task type or scope (bug, feature, maintenance).
Avatars appended to the bugs as the tasks move across the board through departments make it obvious who is working on each task. Tasks are pulled from the list, and pushed to the done / next stage by that person.
As each task gets moved, date entered can be added to make it easier to see the lag times between work coming in and being done. Deadlines can be added as well as extra data such as TFS Item Ids.
Each department has a specific Work in Progress max task number so that teams are limited to their capacity.
Image from mountain goat software
Some really useful information given, the slides of which we'll put up when we get them. We'll certainly be looking to implement a lot of the key features of Kanban in our current Scrum methodology, it fixes some of the issues we sometimes find where inflexibility of times / tasks can be an issue.

Labels: , ,

Øredev 2010 - Day 2 - Tim Jeanes

Ribersborg Kallbadhus

Here's the post-sauna sea pool at Ribersborg Kallbadhus last night. This somehow seemed a good idea despite an air temperature of only 3°C. Exhilarating, but we all shrieked like girls. We also noticed that scarcely any locals were joining in...

Session 1 - Koans and Katas, oh my! - Cory Foy

This was a largely hands-on session where we spent most of the time writing actually code, so there's not too much to blog about beyond the basic principles of katas and koans.

Both are exercises whereby you hone your coding skills outside of the normal flow of day-to-day work.

Katas are essentially simpler exercises where you already know the solution: we worked on the FizzBuzz problem and Conway's Game of Life. The point of the exercise is either to experiment with different ways of reaching the solution (such as implementing TDD or BDD, or using a novel coding pattern), rather than focusing on working out the solution to the problem itself.

Koans, on the other hand, are longer exercises that are more clearly defined by an instructor. These focus on guiding you through the principles of a language or a coding practise, leading you to pick up the concepts by writing simple pieces of code.

Katas are something you'd expect to do many times over to hone your skills in various areas, whereas a koan is something you'd work through once in order to pick up particular knowledge.

Session 2 - A Practical Introduction to Kanban - Joakim Sundén, Marcus Hammarberg

I selected this session as I thought it could be particularly relevant to us at the moment. Kanban is a practice we've been considering taking up at Compsoft, if suitably modified to fit our particular needs.

We started with a hands-on exercise where people simulated the various departments of software development. In this task we were just sticking different coloured dots onto post-it notes, and the point was to experiment with different ways of working to ensure there aren't bottlenecks, that people aren't idle, that the customer is happy with the final result, and that no one feels too pressured.

The two main principles of kanban are to work to an agreed capacity, and only to pull work from the queue when it is required.

Limiting work in progress minimises risk: the shorter your lead times between starting work and getting feedback, the less unconfirmed work there is in the system. The more unchecked work there is, the more potential there is for that work to be wrong - either buggy or just not what the customer requires any more. Work in progress should be limited to the capacity of the team. Working with smaller units of work can help to keep the process time streamlined. Where possible, having a cross-functional team can minimise bottlenecks.

The amount of WIP in a software context is difficult to track as it's not visible: there are no stacks of half-built physical goods sitting around. Thus visualisation is critical. Post-it notes of the wall to track the volume of tasks and where they are in the system helps everyone to see where the work's building up, where the bottlenecks are and hence where the waste is.

Though SCRUM incorporates many kanban principles, it allows for more flexibility than strict SCRUM. Often it can be impractical to set a fixed sprint time-box for a portion of work, especially where (as we often find) we're juggling many different customers simultaneously.

A general principle (though not a hard rule) is to focus on finishing work rather than starting new work. Even though it all has to be done sooner or later, it's generally beneficial to help get items that are already started finished, rather than bringing more unstarted items into WIP. The customer appreciates this as it means the higher priority tasks get delivered sooner, rather than there being more lower priority tasks in the pipeline.

Moving post-it notes representing tasks between columns identifies bottlenecks early and can prompt appropriate reaction. Different coloured notes can represent whatever you want - be it different priorities, different customers, bugs versus features versus change requests, etc.

Joakim Sundén with example kanban board

Each department's columns has a WIP limit. Those these can occasionally be broken, this should always at least prompt a conversation about what the underlying problem actually is. It's also worth including the customer's acceptance as a column, so they can be prompted to keep up with their involvement in the task.

Monday, November 08, 2010

Øredev 2010 - Day 1 - Tristan Smith

Silverlight Bootcamp
Originally due to be given by Shawn Wildermuth (Silverlight MVP) and then by Tim Heuer (Silverlight Program Manager), it ended up being given by Einar Ingebrigtsen Norwegian Silverlight MVP and developer of the Baldur 3D Silverlight engine. He gave a decent comprehensive overview and exploration of Silverlight.
The talk itself was interspersed with loud exclamations from the REST talk next door 'BOOM, BOOM, BOOM HEADSHOT!' and 'What the **** is this application' were heard by the clearly passionate Thoughtworks guys next door.
Starting with a comprehensive overview of what Silverlight is, Einar talked us through the breakdown of the plugin, how the CLR, DLR and rendering engine fit into it.
He covered topics such as Dependency Properties, RoutedEvents, Storyboards, ContentControls, Animations, DataBinding and a lot more. The aim of the talk was to get a 99% coverage of Silverlight so I'll just cover some details, I thought might be of interest, in this post.
RoutedEvents follow a similar path to html DOM events except for some key differences
- Bubbling only goes up the tree (focus, lostfocus)
- EventArgs Handled property can be set to true to handle the event (this doesn't exist for all events)
- Anything can be animated (made to change over time, not just visual properties)

- Custom controls you can attribute up which property to use as the Content property
He gave us a Xaml centric walk around Blend covering:
- Animate colors, values, over time, with easing etc.
- EventTrigger is the only option, which has a single RoutedEvent (Loaded) with a single action, BeginStoryboard
Sample data
- Lets you create sample data that's easily bound in Blend, makes it easier to design when you can visualise the final result.
- Basic types only
- Creates sample data schema, xaml etc in the project and an associated resource file with the items in it
Dependency Properties
Used to add bindable properties.
All UIElements can have an associated resource, these resources apply to the whole hierarchy of that UIElement.
Resources are stored as dictionaries so they have a key to get access to them and can store anything (a Class instance for example).
MergedResourceDictionary allows you to pull in dictionaries from elsewhere
Styling doesn't mean just visual styles, you specify TargetType but can change any property at all.
Styles are inheritable making base styles with overridable style parts possible.
Controls can have states and transition between them, Focused, MouseOver etc.
Binding has Validation hooks - ValidatesOnException, ValidatesOnNotifyDataErrors if the object being bound implements IDataErrorInfo + INotifyDataErrorInfo
Control value default
On controls you can set properties of TargetNullValue='None' and FallbackValue='Data Context not set' so that you can have default values for when nothing is specified and when data has not been bound.
Exposed properties on your object model can declare the TypeConverter to use (To allow scenarios such as converting a selected product code into a product instance).
You point to a TypeConverter by attaching an attribute
Blend makes it easy to edit templates based on existing controls, this is often a handy starting point. In order to get your bound property content to appear, you need to ensure you add a ContentPresenter control
You get access to two, DispatchTimer and the CompositionTarget Rendering event (which is fired as many times as you have MaxFramesPerSecond configured).
The DispatchTimer runs on its own thread.
To work against the UI, you need to go via the Dispatcher
LocalConnection API
- Used to communicate between SL instances on a page��
Silverlight uses its own font engine, you get 9 fonts by default but you can embed your own fonts.
Introduced in Silverlight 3, it's surprising fast, Einar's 3D engine project makes a lot of use of it.
Tooling is a bit rubbish at the moment, you have to manually change the access modifier in the Resource file but then because the tooling doesn't modify the constructor to be public, you have to derive the resource class to add a public constructor.
- DataContractSerializer and JsonSerializer only
- References are maintained (circular references sorted for you)
- IgnoreDataMember to skip serialization of properties
Is still lame, no paging support, pixel not DPI based. If your image is bigger than the available print area, it won't intelligently continue, it'll lose the excess.
- The cool feature, is that you can pass specific UIElements to be printed.
- Add service reference handy proxy generation
- Validation for databinding is a pain because you lose IDataErrorInfo in transit.
ViewModel contains State and Behaviour
Built in Commands mechanism - requires a new class for each one.
MVVM Light give you some time saving Behavioural additions.
You create your commands as methods on your ViewModel and call delegates passing your method.
Event aggregation - a contract (message type) that view models can subscribe to / publish. MVVM Light has this called Messager.
Einar showed us a convention he uses where he creates a directory per feature, in this case it was a Customer folder with a View, ViewModel and CustomerDataSource.
The ViewModel encapsulates the state and behaviour. It uses a generic DelegateCommand to wire up to a local method (Load for example) rather than implement the full ICommand.
MVVM Light has an implementation of the delegate calling code.
Jeff Wilcox pointed us at the SilverlightToolkit
Is a library on CodePlex ( that has a bunch of handy controls such as DockPanel, ViewBox and BusyIndicator.
Also has a comprehensive samples app which lists the controls included but includes examples of styling, templating, selection, events, databinding etc for each control. Pretty handy!
Jeff showed us a really nice styled, templated app called Bugaholic he wrote that looks a lot like the Zune client.
Einar covered some unit testing, Jeff wrote the Silverlight Unit Testing framework so we saw a bit of that to end with.

Labels: ,

Øredev 2010 - Day 1 - Tim Jeanes

Øredev - not the plushest conference venue

Øredev - the only conference I've known to be held in a converted slaughterhouse.

A bootcamp in Silverlight - Jeff Wilcox, Tim Heuer Einar Ingebrigtsen

I've tinkered a little with Silverlight at a basic level in the past, but not really used it in anger. This intensive session took us from the very basics through to cover around 99% of Silverlight within a single day, so I've only blogged the points that stood our for me.

RoutedEvents - events that a parent can also receive (Focus, LostFocus, etc.) - these bubble all the way to the root of the VisualTree. Can set the Handled property of EventArgs to stop bubbling, though this isn't available on all such events.. OriginalSource holds information about the source of the event.

ContentControl - the base class for classes that have content (e.g. Button, TextBlock).

ItemsControl - the base class for controls that have items (just as lists, etc.)

HierarchicalDataTemplate - the base class for hierarchical structures such as TreeView.

Animation - all done through storyboards. Any property can be animated - not just visual things (e.g. you can animate the value of a string). In all animations you specify keyframes and Silverlight interpolates between them using the specified easing. nimation storyboards can be started in code, or via triggers in the xaml.

Sample Data - This is a powerful feature of Blend. You can easily specify a data structure (Customer has FirstName, LastName, Photo, etc.) and mock data will be generated for you - lots of lorem ipsum-like text and arbitrary images in our case. This makes it really easy to get started with a data-driven app that you can even show to a customer right away.

DependencyObject and DependencyProperty - When making your own controls, can define DependencyProperties. This enables properties to be animated; it also provides two-way dependency, so the view is updated with changes made in code as well as the code being notified of changes made to the value via changes made in the view.. This points to the actual property whose value is to be changed. You can also specify metadata such as the default value and a callback method that will be called whenever the value is changed by some action in the view.

This makes for quite a bit of extra typing and non-refactorable code (the actual property name is specified as a string in the DependencyProperty definition, for example). It's worth using a generic wrapper that will register the DependencyProperty for you. Einar's set up some sample code of how to do this, available here: [.]

Resources - As well and application-wide resources, all UIElements can have resources available for their scope. Though resources are usually used for styling, resources can be any objects. Only static resources are available in Silverlight - WPF's dynamic resources can't be used here.

Styling - this goes way beyond the powers of CSS: any property can be styled - including ones that aren't visual. Styles can be inherited from one another using the BasedOn keyword.

Visual States - Controls can have different states (e.g. MouseOver, Focused, etc.). Using the VisualStateManager you can set styles for different states and the animations between them.

Markup extensions - These allow you to use pseudo-values for properties, such as {Binding}, {StaticResource}, etc.

DataContext - All UIElements have a DataContext, which is inherited from its parent by default.

Binding data - Different modes are available: OneWay (the default, which only takes data from the object to the view), TwoWay (which sends data back), OneTime (which reads the data once at start-up and never updates).

IValueConverter can convert string values in the model to a different value that is used on the view. This can also work both ways.

String formats, null and fallback values can also be defined.

Attached Dependency Properties - these allow you add your own properties to the existing properties on a DependencyObject. You can see these in action in the Grid control: it adds the Grid.Row and Grid.Column properties to child elements that appear within the Grid.

Element-to-element binding - One element can bind to the properties of another element. This can be useful, for example, in list/ detail binding.

Silverlight promotes using an asynchronous model, so INotifyPropertyChanging and INotifyPropertyChanged interfaces are used to mark the beginning and end of the async operation.

TypeConverter - Everything in xaml is a string, so these are used to convert between objects and strings between the view and the model. They are defined through attributes on types or on DependencyProperties.

Offline support - Isolated storage is available for storing data locally. Silverlight can also be run out-of-browser. The API provides methods to detect network availability and events are raised when the network availability changes.

ChildWindow - an easy way to create modal controls. Watch out though - it's easy to tab from this control back to the parent. It's a bit tricky to work around this bug.

DispatchTimer - a timer for running code at a predefined point in time. This runs on its own thread so you need to use the Dispatcher to execute operations on the UI thread.

Local file access - you can't access any old file on the hard drive; however OpenFileDialog and SaveFileDialog are available to ask the user to access files.

Local Connection API - enables you to communicate between multiple Silverlight instances on a single HTML page.

Fonts - Silverlight has its own font engine to break the dependency on the OS, thus ensuring it will render the same everywhere. Nine fonts are included in the runtime, but you can embed your own or access certain ones that you can (hopefully) assume exist in the OS. TrueType fonts are supported.

WriteableBitmap - this enables you to create your own bitmaps dynamically at runtime. It's surprisingly performant.

Printing - Any UIElement can be sent to the printer. However, it's pretty limited. It doesn't always look great as it's pixel-based. There's no paging support - anything you print will come out on a single page.

WCF Services - Adding a Silverlight-enabled web service to your server application really adds a regular WCF service - but it also sets everything up for Silverlight consumption in the web.config.

MVVM - the Model - View - View Model model works really well with Silverlight. The View Model is where you spend most of your development time in Silverlight. It should contain business logic relevant to the frontend, but not view-aware. It typically connects to the server through services. In terms of state, it contains as much model-like information that the view needs, with the application logic state.

Though MVVM costs a bit in terms of the initial learning curve and early development time (though it's less uncomfortable if you're already used to ASP.NET MVC), it's worth it for the separation of concerns and code testability and maintainability. It also makes it a lot easier to make drastic changes to the UI without breaking the application.

Silverlight toolkit - Available at, this is an open source library of useful Silverlight components that may one day make their way into the core Silverlight library. It includes tools for WP7 development.