I still have loads of videos to convert, next one in the line are Sal's ones :-)

Principles of lean UX:

1. team of 3 people: 1 designer + 1 product manager + 1 developer > highest velocity possible  > quickest learning cycles
2. externalise : kanban for designers
3. goal driven and outcome focused 
4. repeatable and routinized 
5. FLOW think/make/check
6. focus on solving the right problem
7. Recognize hypotheses and validate them
8. Research with users is the best source of information
9. Generate many options and decide quickly which to pursue

Lean UX Practises:

1. write the test first 
2. user quote need as sprint name
3. wireframe check
4. designer developer pairing
5. UX & Product Mgt participate in standup meetings daily
6. validation step
7. retrospective periodically

The Four Steps to the Epiphany - Steven Gary Blank

The Entrepreneur's Guide to Customer Development - Brant Cooper, Patrick Vlaskovits

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses - Eric Ries

Extreme Programming Explained: Embrace Change - Kent Beck, Cynthia Andres

Lean Thinking: Banish Waste and Create Wealth in Your Corporation - James P. Womack, Daniel T. Jones 

Rocket Surgery Made Easy: The Do-it-yourself Guide to Finding and Fixing Usability Problems - Steve Krug

Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers - Dave Gray, Sunni Brown, James Macanufo 

Don't Make Me Think!: A Common Sense Approach to Web Usability - Steve Krug 

 

@SaintSal Externalise! It's about post-it notes and sharpies man! 4 people can stand around it together and talk about it. #luxr

@SaintSal Repeatable and routanised. Startups are notorious in making up ways to work. Work in repeatable ways that get results. #luxr

@Ultraman : Ux own customer empathy and work with developers to create something realistic is not only a #LeanUx #LUXr principle but a #design one

@SaintSal Pairing with designers saves a lot of time. To see how much, start with a test - pairing with a tricky bit. #luxr

@SaintSal Test-driven devel is for designers too! Why are developers allowed to get it wrong but designers are expected to get it right at 1st? #luxr

@SaintSal: @luxrco on emergent rituals vs strict processes: try starting with more rigidity then relaxing as it becomes habit. #luxr

@jacwex: Tom McCoy on product stewardship http://www.cooper.com/journal/2011/02/lean_ux_product_stewardship_an.html #luxr

@Ultraman : 3 person startup means you all have to chip in to fill gaps. Do what ever it takes! #LeanUx #LUXr

@hmitsch: Roman Voting: it's all about not talking and making decisions. #LUXr

@pmgandhi Behaviours are symptoms. Find the real problem #luxr

@pmgandhi: Research is not about surveys, it's about conversations with people. Get them to tell you a story #luxr #LeanStartup

@pmgandhi: Demographics less imp than behaviour and needs. Rich socialites and farmers use amazon alike #LUXr

@SaintSal @ultraman is talking about #gamestorming. More info on that at http://gogamestorm.com and http://leanca.mp too! #luxr

@mahemoff Apple UX works according to one persona, his name is "Steve ". Elsewhere personae are actually useful. #luxr

@javame Innovation at Google http://slidesha.re/prAolY the paper prototyping kit to build the park-jerk app I just mentioned at #luxr

@SaintSal: With personas, look for edge cases where if you design for them, you get the common user "for free." #luxr

@SaintSal: Pairing with designers saves a lot of time. To see how much, start with a test - pairing with a tricky bit. #luxr

@SaintSal: A good tool to track your learning is the risk log on thestartuptoolkit.com by Londoner @robfitz #luxr cc @luxrco

@javame: @ericries article about Vanity Metrics vs. Actionable Metrics http://bit.ly/q4lSID #luxr

@Ultraman : Build it and test it as early as possible. It is the only way to truly know if something works. #LeanUx #LUXr

@javame: if you are stuck just go faster! @clevergirl = legend #luxr

@Ultraman : If it does not work pull it. Knee jerk reactions are affordable when you do not have a brand reputation yet. #LeanUx #LUXr

@whatterz: "Test in pennies, spend in dollars." #LeanUx #LUXr

@hmitsch: Move from "Product Owner" terminology to "Product Stewardship" understanding, creating things together. We are one product team. #LUXr

@javame: empathy mapping http://t.co/F6gI70F to develop personas #luxr”

@SaintSal Usability testing is like your liver. It won't keep you alive but it will keep you from dying. #luxr #LeanStartup

@javame: http://slidesha.re/pGLFiM Janice aka @clevergirl slides are here! #luxr

Hi Antonio,

 

I hope you are well. I have come across your CV on my database as I am currently recruiting for a number of Developer roles for a company in Central London, operating in a Dynamic Language environment (primarily Ruby and Clojure).

 

My client are at the fore front of Agile practices as they work in a "Post- Agile" environment or a "Programmer Anarchy" environment which was introduced and led by a former VP and Director of Strategy and Plans from ThoughtWorks. 

 

In case you have not come across the term "Programmer Anarchy" before (it is very new as far as I understand), it is an environment that empowers the Developers to take full ownership of the project and work off of your own initiative as opposed to being set projects and targets by PM's / BA's, etc..

 

My client is able to pay a very competitive salary in Central London and their benefits scheme is healthy and innovative, offering innovation leave where you are able to work on your own projects. Although the salary is competitive, my client is looking for Developers who are looking to work in one of the most forward thinking environments in the industry and they will quiz you on your outside work interest (own projects, conferences attended, github accounts, etc...) 

 

The CV I have of yours (I appreciate that it may be out of date and I apologise if this is no longer relevant) looks very interesting so I would like to speak to you about this opportunity.

 

Does this sound interesting to you and if so, what time and number can I call you on?

 

Thanks Antonio,

 

Regards,

 

The Recruiter

I am so bored and disgusted of the flickr UI (and relative poor usability) that this afternoon I started a new side project. I called it vanderlyle¹ and it's a simple ruby app built with the excellent gems padrino & flickraw. The idea is to have just a stream of pics, the content are the shots, dear flickr, the rest is just noise and it disturbs me. Flickriver does something very similar, but again, there are way too many options, too much text around the images, I want just to see the pictures, in full screen. Right now the images are loaded on the fly, I need to write a cronjob (whenever with mongoid will do it) to store the urls locally, that should speed up the page load. Given that the flickraw api are amazingly easy to use I am also thinking of a simple script to "push" the images straight on flickr, from command line, obviously I do hate as well how iphoto and flickr uploadr handle the upload process. Good idea? Bad idea? Waste of time? I don't know yet, comments are more than welcome, if there's any interest in such an app it would be rather easy to support multiple users. [1] vanderlyle comes from here

The search team at forward does a lot of ETL, data is our daily business. Recently I wrote a script that:

1. Collects some data from our Hadoop cluster
2. Calls a 3rd party API via HTTP
3. Pools the 3rd party API waiting for the requests to be processed
4. Downloads and stores locally the result of the 3rd party call

I want now to share what I learnt writing this script. Drop OOD, think functional I didn't wrote a single domain object, I used just hashes, they comes from Hive, they get used to call the external API, the xml that comes from the API becomes an hash, the data gathered from there goes straight in Mysql as CSV. I wrote the script in ruby, but I wrote few functions, the application is Stateless but stageful. There's no state but every single stage status is saved in mongo. In this way the script can fail at any point but always recover in a consistent state and start again from where it did stop. Nokogiri does crash for a bug every noun when parsing the API request page where I get the current status of the 3rd party processing. If anything can go wrong, it will I didn't care of fixing that bug or understanding why it does crash, the script will recover and try again till the parsing is successful. I don't need to be fast, cos the 3rd party server is rather slow in processing our requests. Speed is not a requirement. Consistency is. The 3rd party server went down as well quite few times, for networking issues and load. I just keep polling and let the script fail on timeout, it will start again in a 10 seconds and try again. Forget about REST, the important stuff is the rest Data is the important bit, not the way you get it. The URL provided by the 3rd party is not rest, so what? What I care about is the Data that they give to us. Being rest or not won't change my life, the value is in the content not in the transport. RTFM Read the fucking manual. I actually spent more time tuning/troubleshooting MySql (where I store the data) rather than writing the script, that deserves a full separate post, but the point is: read the manual, read the manual page till the end. Drop frameworks I use Sequel for the DB connectivity but I just use it to efficiently get the connection to the DB, I actually use plain SQL so that at least I know what's going on, when you start having tables with 80 Millions rows you better start being careful about what's going on. In conclusion, the funny bit is that web application are ETL too :-) What I wrote is valid for writing web applications too. The wikipedia page says: The typical real-life ETL cycle consists of the following execution steps: Cycle initiation Build reference data (think about populating drop downs, static data) Extract (from sources) (user input) Validate (validate user input) Transform (clean, apply business rules, check for data integrity, create aggregates or disaggregates) (business logic) Stage (load into staging tables, if used) (store) Audit reports (for example, on compliance with business rules. Also, in case of failure, helps to diagnose/repair) (analytics, audit) Publish (to target tables) Archive Clean up

Rory Gibson wrote a nice write up of Fred's open space talk that did happen last Monday at the 10th XPDay in London. Jamie wrote a comment on that post that deserves a reply. He says:

You won’t know it works until later… What debt are they now in? What happens when complexity grows? How do they resolve conflict? Many start ups work because debt is hidden. If peer pressure is their number 1 hr strategy they will stagnate and *not* be able to respond to changes in their business.

The comment was mainly on our philosophy, another commenter on the blog post describes it as JFDI. During my talk at the Agile Day I've got a comment that I forgot to mention in my post-talk write up. One guy on the audience said, well you guys just design your software with a Unix Philosophy. Oh man, this is so true. It's even on wikipedia. I particularly like theMike Gancarz check list of the Unix Philosophy:

• Small is beautiful.
• Make each program do one thing well.
• Build a prototype as soon as possible.
• Choose portability over efficiency.
• Store data in flat text files.
• Use software leverage to your advantage.
• Use shell scripts to increase leverage and portability.
• Avoid captive user interfaces.
• Make every program a filter.

Then let me paste here also the golden rules from Eric Raymond:

• Rule of Modularity: Write simple parts connected by clean interfaces.
• Rule of Clarity: Clarity is better than cleverness.
• Rule of Composition: Design programs to be connected to other programs.
• Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
• Rule of Simplicity: Design for simplicity; add complexity only where you must.
• Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
• Rule of Transparency: Design for visibility to make inspection and debugging easier.
• Rule of Robustness: Robustness is the child of transparency and simplicity.
• Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
• Rule of Least Surprise: In interface design, always do the least surprising thing.
• Rule of Silence: When a program has nothing surprising to say, it should say nothing.
• Rule of Repair: When you must fail, fail noisily and as soon as possible.
• Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
• Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
• Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
• Rule of Diversity: Distrust all claims for "one true way".
• Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Now believe or not but you can trash away lots of books just following these rules. Unix is, IMO, the most stable software humanity ever wrote (think about unix, linux, macos and so on) This is the way we work. We do have technical debt and we have plans to rewrite our small applications, we do that continuously, since they are small, modular, with a single responsibility (think about cat, ack, grep, etc... do) it's never a big deal.

In my previous blog post I did write about most of the conversations and feedbacks I've got after the Italian Agile Day. In this one I want to address the software design. Rewrite preferred over Refactoring As I said during the speech we don't do that much refactoring anymore and we rather throw away the code and rewrite it from scratch. Paolo Polce said more or less something like this:

"You guys are good and write good enough code already, that's why you need less (or none) refactoring"

It's probably true, he gave me a good explanation, from a scale from zero to ten we probably write code that is already a six or a seven, so there's little need for refactoring. I've to say that we do refactor a bit, especially when a new feature comes in or when we re-open the code base after a week or more. The big difference is that if we don't like it at all anymore, if there are some code smells, if the code is resistant to change we just rewrite it. Also, one type of refactoring we do often is to reduce the codebase size. I truly believe that the main goal of refactoring should be keep the codebase small. I had a chat with Mike the other day and I found that he's doing the same thing in his team, he keeps trying to keep a part of his code base under 200 lines, even if they are adding new features. I used to be obsessed in writing small classes and small methods. Let me tell you, that's just nothing compared to writing small modular applications. Also, small classes and short methods too often imply huge codebases: it's hard to understand the intent of a system when its intent is scattered through hundred of files. Bounded Contexts We do use bounded contexts and this helps to keep the applications simple, easy to change, to rewrite when needed. It does allow us to use the right tool for the job (picking up node.js or clojure or plain ruby) for the task. Aggregation Talking with ziobrando after the conference I've realized that we implement in most of the projects aggregates, as DDD defines them:

Cluster the Entities and Value Objects into Aggregates and define boundaries around each. Choose one Entity to be the root of each Aggregate, and control all access to the objects inside the boundary through the root. Allow external objects to hold references to root only. Transient references to the internal members can be passed out for use within a single operation only.

Using noSQL helps a lot. But we implement it also with mysql. The key is to throw away all the frameworks and the patterns that dominated the market of the last 5/6 years: we don't use Sequel Models, we don't use (rails) Active Records. Most of the time we don't even write domain objects, we just use hashes. In functional programming this is definitely easier to achieve, however, in ruby you can obtain pretty good results as well. Blue Green Deployment The way we deploy our code to production has been well explained by Martin Fowler in this blog post. I admit I didn't know the name of this technique, I was just using it. Thanks again to ziobrando for suggesting me the name! DSLs preferred over Patterns As I said in the presentation I can't remember the last time in the last six month that I did introduce or use a pattern in my code. We do use tiny frameworks and DSLs rather than patterns. I think that this is the way to go. Sinatra is a brilliant dsl for writing web applications, haml is a lovely dsl for writing html, sass is a brilliant dsl to write css, capistrano, rake... It's all about dsls.

I am just back in London and I am full of notes, thoughts and comments on the presentation I gave at the 7th Italian Agile Day. To start with I want to thank all the guys at Forward that created such an environment, they are in the credits at the end of the presentation, but for this blog post I want to put them first. Secondly, I want to say thank you to all the audience, I never had such a brilliant audience, the room was full and I struggled to finish the presentation cos there were something like ten hands up or more. And the conversation didn't finish there, outside and for the whole day I did talk with so many great developers who gave me so many insights that I am now struggling to remember all of them. And that's the reason of this blog post. To give you an opportunity to better understand my presentation (especially if you weren't there) and to write what I learned after it. Agile is now mainstream, with all the consequences Nusco gave us an awesome keynote, at a certain point he did quote the original paper of the waterfall methodology which sounded weirdly similar to the agile one. I did check and he was right, not only. I saw the waterfall diagrams and now I remember where I saw them the first time. Craig Larman showed them to the audience, at the Italian Java Conference. It must have been 2004 or 2005. I can't remember. I love the part on the paper where the author admits:

I believe in this concept, but the implementation described above is risky and invites failure.

The point is that since Agile is becoming mainstream it's getting polluted by certifications, labels, zealots, people reading and learning about agile but forgetting that implementation can be risky and lead to fail, same as waterfall. My presentation tried to explain that you should use just the right tools for the context you are in and avoid using the full stack just because you heard of it. As ziobrando put it on twitter: " Great insights from @javame yesterday evening. Funny to see how contexts put dogmas in perspective." emadb did tweet something like: @javame is a revolutionary, we should reflect on his good session, a lot. I have to say that it's pretty sad to be called a revolutionary in 2010, as I said before, we are just following the Agile Manifesto. So, what's going on? What happened to Agile? Why Agile these days does mean following books and papers over individuals? Why Agile in these days does mean writing tons of tests rather than delivering working software? Why Agile these days does mean strictly following a set of practises rather than responding to change? Why Agile these days does use external business analysts rather than direct customer collaboration? These are the questions to reflect on. I don't want to be a revolutionary, we just follow the manifesto, but so many teams lost the original plot these days. Agile is not dead, agile now needs to prove that he can survive in a mainstream/enterprise context without getting polluted.