The search for quality
(or how to negotiate best practice in
a commercial environment)
marcus alexander
EMC Consulting
marcus.alexander@emc.com / mdja68@hotmail.com
twitter: #mdjalexander
• What is quality?
• Understanding requirements
• Building stuff
• ... with other people
• Testing?
• Dirty tricks
• Home ...
What is quality?
Time for a project
?????????????????
♡ ☠
• Not extensible
• Slow rendering
• It works
• It's concise
♡ ☠
• Unverifiable code
• Impossible to modify
• Looks swanky
• Took no time at all
♡ ☠
• Global scope
• Not flexible
• No dependencies
• Fast rendering
♡ ☠
• Verbose
• Took longer to write
• Extensible
• Well structured
A high quality solution is
one that meets the
requirements
... If you know what the
requirements are.
Valid XHTML strict, CSS3, jquery 1.4.3,
TDD, GITHUB, object-oriented, chrome 4
compatible...
These are your requirements
"The main requirement is that it's
live before Christmas"
Client preoccupations
R.O.I.
Budget
Tech
Deadline Features
Style
Client preoccupations (microsite)
R.O.I.
Budget
Tech
Deadline
Features
Style
Client preoccupations - Intranet
R.O.I.
Budget
Tech
Deadline
Features
Style
Ask some questions
Simple questions
• When?
• What?
• For how long?
Who are you delivering to?
Simple questions
• Hosting environment?
• Folder structure?
• File naming convention?
• Libraries?
• Browser support?
What's at the other end?
"It's just a bit of
HTML!"
... Get them agreed!
You may not always like it
Charles Pinsent
Charles Pinsent
"Choke on it"
Process and planning...
Client
UX
Design
Me
Client
Dev team
Test team
Client
Interface dev team
Client
UX
Design
Me
Client
Dev team
Test team
Client
Interface dev team
Client
UX
Design
Me
Client
Offshore Dev team
Test team
Client
Offshore Interface dev team
Build
Build Test Fix Deploy
Support
SetupTech
plan
"But it's just a bit of
HTML!"
A bit of engineering
Preparing for the future
Whatever you do,
it will change
so make it easy
Understand what will
change, and what won't
change
"But it's just a bit of
HTML!"
Protect the build
Making life easier
Source control, bug
tracking, defect
management...
ANT
ant.apache.org
"Patterns can be grouped to sets and later be
referenced by their id attribute. They are
defined via a patternset element,...
Release 4.zip
"We have updated line 1342 of
import.css to fix incompatibility
problem with our JSP"
Developers, developers,
developers
Working with other people
Coding standards
Coding standards consumption chart
Don't read
Read
Follow
Agreed practices
and code reviews
A one page document,
and examples
... Be prepared to justify it
Choke on it
Those other people
XOQA(XML-based Object Query Architecture)
™
"The code uses a lot of very
complex regular expressions, it
would be too difficult to change it"
Bugs
Somebody has to fix them
Breakdown of the time I have spent...
Coding
Fixing
bugs
Breakdown of the time I have spent...
Coding
My bugs
Somebody else's bugs
Close-up examination
Known issues
Requirements
Bug tracking software
Testers
Bug reports will always
be rubbish
"Postcode box not proper"
"The text looks fuzzy on IE6"
In IE6, if Truetype is enabled in the
operating system, text in an element
with the opacity filter applied will render
poo...
"Slight shadow of David Blunkett
seen in right-hand corner of page"
100 bugs is not scary
Bug breakdown
Mis-reported
Bugs
Duplicates
Close-up examination
Known issues
Requirements
Maintain your sanity
Dirty tricks
The stuff you don't tell your client
It is fine may be acceptable to
release buggy code
"It's a known issue"
It is fine may be necessary to build
something that doesn't work
Choke on it
Some home truths
❽
The user is not the enemy
If they don't understand it, that's
your problem, not theirs.
The client is not the enemy
If they don't like it, that's your
problem, not theirs.
It may not go live
Don't worry about it
Don't expect them to understand
It's your job to understand it, not
theirs.
"All the problems on this project
were caused by this new CSS
technology"
circa 2008
... that's all
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
The search for quality
Upcoming SlideShare
Loading in...5
×

The search for quality

609

Published on

How to negotiate best practice with clients on HTML and web projects.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
609
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Let's play a game. I'm guessing some of you have seen the Million Pound Drop. Well this is a bit like that,
  • except you're pouring your client's money down the drain. So – we have the requirements, lets try and create a million pound solution. Over to the developer.
  • Doing well. See, I even put a comment in at the top. Bit of jquery, Easy Peasy. Job done.
  • "I'm on fire, baby" - awesome. Does all the work for me.
  • It doesn't matter what 'it' is.
  • This is Charles Pinsent. I couldn't find any picture of him on the Internet so I had to recreate him from memory. Charles Pinsent teaches sales and negotiation. He's also a complete maverick, and a genius. He literally did sell sand to the arabs – 100,000 tons of it. To make one of Dubai's new islands. you're probably wondering why i'm saying all this. I went on one of his negotiation courses and at the end of the day he asked everyone what was the one thing they would rember. Everyone was blah blah this and blah blah that, and when he got to me the one thing I remembered was -
  • You've got to choke on it. You may not like it, but you don't say anything – because somebody is trying to hand a load of money over to you. So when the client asks for something and you thing it's wrong – you might say so – or you might realise that it's time to shut up and say yes. It's not your website, it's theirs. It's not your money. It's theirs.
  • What normally happens is that a project manager will stroll over to a developer, wave a couple of designs at them and ask how long it will take. Developer then umms and aahs for a minute, and probably says ...
  • About two days. Which is probably about right – for how long it will take to build it. So the PM takes half a day off because you probably exaggerated, then rounds down to a day to impress the client. Except – chances are - there's a bit more to it than just that. If you look at a more realistic version –
  • .... at which point somebody has a heart attack. And they'll probably say the same thing I've heard over and over again -
  • ... CMS or Design Team
  • Your build environment should have your requirements, not the client's requirement
  • Ant is my best friend.

    Ant is a build tool. It is also the most arcane tool in the history of man – it makes regular expressions make sense.
  • It has a rubbish logo
  • And the documentation is the work of the unsane. But it's incredibly useful.
  • Ant is a build tool. It is also the most arcane tool in the history of man – it makes regular expressions make sense.
    And the documentation was written by the insane. Here's an example.
  • Surprisingly useful.
  • It also takes things like this – CSS code nicely broken down into functions for easy code management
  • into this, which is far better for delivery. Not only is it compressed and coalesced into a single file, it's pretty darn near impossible to work with. Which means your client won't tamper with your code. you hope.
  • Until you receive an email like this...
  • If you're on a big project, chances are you'll be working with other people. Which isn't always easy. Especially for developers, who don't like anyone messing with their code. There are ways to make it easier...
  • Coding standards. Wherever I've worked, somebody at some point has said – we must have some coding standards! So somebody goes away for a couple of weeks, writes feverishly and returns triumphantly with a document.
  • .... So what can you do?
  • Here are some of my rules for CSS. One declaration per line. Tabs for indenting, not spaces. A space after the colon. Margins first, then paddings. Always specify margins and paddings in 4 units or one. I could write that down, or just show it like this.
  • And if you are creating any rule, be prepared to justify it. All those things i just listed – that's not just vanity - I can give a sound, practical reason for every single one of them.
  • And if you're expected to follow somebody else's rules, choke on it. It's far more useful on a project to be consistent than to be right. the standards are there to make work portable, as well as to make it work.
  • Developers are an awkward bunch. Almost as difficult as designers. Some love to code, and some will do anything they can to avoid it.
  • This guy will do anything he can to anything he can to avoid writing code. It's easier to spend 3 weeks integrating a plugin than 2 days writing something from scratch.
  • If you think they're bad, the opposites are the engineers. This guy built himself a rocket, to beat the traffic to Ikea. Only he forgot to put a boot in it to carry his flatpacks home. In the days before wordpress every developer created at least one CMS - Agencies around the world are littered iwth these home-built tools. I built one. I called it
  • It was amazing. It worked iwth an XML-based syntax for defining data structures and rules, and squirted out a website. I built a parser in XSLT to interpret an XML based language I defined myself. It was brilliant. It was only 6 months later I realised I'd built a shit version of XSLT.... In XSLT. You live and learn.
  • The developer who doesn't want you to see what they are doing, or how they are doing it.
    Anecdote – the developer who literally built an enclosure around his head and monitor using cardboard boxes
    Anecdote – Olaf and the regular expressions
  • The developer who doesn't want you to see what they are doing, or how they are doing it.
    Anecdote – the developer who literally built an enclosure around his head and monitor using cardboard boxes
    Anecdote – Olaf and the regular expressions
  • But actully, I'm being a bit harsh on myself there. If we do a CSI-style forensic examination of that little slice of 'my bugs' what we actually see is that
  • 30% are known issues, and the rest are requirements that nobody knew about before I put them in there. So how do you deal with the bugs?
  • It's great. Really useful.
  • Even better if you have testers but don't kid yourself.
  • So I fired up my VM, launched IE6, waited ten minutes for it to start, went to the page, and everything looked fine. So I said – nothing to see here. And then they sent a screenshot.
  • Amazingly, they weren't winding me up. The text really did look fuzzy.
  • If you have 100 bugs, you may find 50 are duplicates, 30 are known issues, 10 are change requests, and of the remaining 10, 5 are caused by the same one thing. The problem is, 100 bugs is scary for the Project Manager, and terrifying for the client.
  • If you have 100 bugs, you may find 50 are duplicates, 30 are known issues, 10 are change requests, and of the remaining 10, 5 are caused by the same one thing. The problem is, 100 bugs is scary for the Project Manager, and terrifying for the client.
  • And if you're expected to follow somebody else's rules, choke on it. It's far more useful on a project to be consistent than to be right. the standards are there to make work portable, as well as to make it work.
  • Transcript of "The search for quality"

    1. 1. The search for quality (or how to negotiate best practice in a commercial environment)
    2. 2. marcus alexander EMC Consulting marcus.alexander@emc.com / mdja68@hotmail.com twitter: #mdjalexander
    3. 3. • What is quality? • Understanding requirements • Building stuff • ... with other people • Testing? • Dirty tricks • Home truths
    4. 4. What is quality?
    5. 5. Time for a project
    6. 6. ?????????????????
    7. 7. ♡ ☠ • Not extensible • Slow rendering • It works • It's concise
    8. 8. ♡ ☠ • Unverifiable code • Impossible to modify • Looks swanky • Took no time at all
    9. 9. ♡ ☠ • Global scope • Not flexible • No dependencies • Fast rendering
    10. 10. ♡ ☠ • Verbose • Took longer to write • Extensible • Well structured
    11. 11. A high quality solution is one that meets the requirements
    12. 12. ... If you know what the requirements are.
    13. 13. Valid XHTML strict, CSS3, jquery 1.4.3, TDD, GITHUB, object-oriented, chrome 4 compatible... These are your requirements
    14. 14. "The main requirement is that it's live before Christmas"
    15. 15. Client preoccupations R.O.I. Budget Tech Deadline Features Style
    16. 16. Client preoccupations (microsite) R.O.I. Budget Tech Deadline Features Style
    17. 17. Client preoccupations - Intranet R.O.I. Budget Tech Deadline Features Style
    18. 18. Ask some questions
    19. 19. Simple questions • When? • What? • For how long?
    20. 20. Who are you delivering to?
    21. 21. Simple questions • Hosting environment? • Folder structure? • File naming convention? • Libraries? • Browser support?
    22. 22. What's at the other end?
    23. 23. "It's just a bit of HTML!"
    24. 24. ... Get them agreed!
    25. 25. You may not always like it
    26. 26. Charles Pinsent Charles Pinsent
    27. 27. "Choke on it"
    28. 28. Process and planning...
    29. 29. Client UX Design Me Client Dev team Test team Client Interface dev team
    30. 30. Client UX Design Me Client Dev team Test team Client Interface dev team
    31. 31. Client UX Design Me Client Offshore Dev team Test team Client Offshore Interface dev team
    32. 32. Build
    33. 33. Build Test Fix Deploy Support SetupTech plan
    34. 34. "But it's just a bit of HTML!"
    35. 35. A bit of engineering Preparing for the future
    36. 36. Whatever you do, it will change
    37. 37. so make it easy
    38. 38. Understand what will change, and what won't change
    39. 39. "But it's just a bit of HTML!"
    40. 40. Protect the build Making life easier
    41. 41. Source control, bug tracking, defect management...
    42. 42. ANT ant.apache.org
    43. 43. "Patterns can be grouped to sets and later be referenced by their id attribute. They are defined via a patternset element, which can appear nested into a FileSet or a directory- based task that constitutes an implicit FileSet. In addition, patternsets can be defined as a stand alone element at the same level as target — i.e., as children of project as well as as children of target."
    44. 44. Release 4.zip
    45. 45. "We have updated line 1342 of import.css to fix incompatibility problem with our JSP"
    46. 46. Developers, developers, developers Working with other people
    47. 47. Coding standards
    48. 48. Coding standards consumption chart Don't read Read Follow
    49. 49. Agreed practices and code reviews
    50. 50. A one page document, and examples
    51. 51. ... Be prepared to justify it
    52. 52. Choke on it
    53. 53. Those other people
    54. 54. XOQA(XML-based Object Query Architecture) ™
    55. 55. "The code uses a lot of very complex regular expressions, it would be too difficult to change it"
    56. 56. Bugs Somebody has to fix them
    57. 57. Breakdown of the time I have spent... Coding Fixing bugs
    58. 58. Breakdown of the time I have spent... Coding My bugs Somebody else's bugs
    59. 59. Close-up examination Known issues Requirements
    60. 60. Bug tracking software
    61. 61. Testers
    62. 62. Bug reports will always be rubbish
    63. 63. "Postcode box not proper"
    64. 64. "The text looks fuzzy on IE6"
    65. 65. In IE6, if Truetype is enabled in the operating system, text in an element with the opacity filter applied will render poorly (aka "look fuzzy") if there is no background style set on the element.
    66. 66. "Slight shadow of David Blunkett seen in right-hand corner of page"
    67. 67. 100 bugs is not scary
    68. 68. Bug breakdown Mis-reported Bugs Duplicates
    69. 69. Close-up examination Known issues Requirements
    70. 70. Maintain your sanity
    71. 71. Dirty tricks The stuff you don't tell your client
    72. 72. It is fine may be acceptable to release buggy code
    73. 73. "It's a known issue"
    74. 74. It is fine may be necessary to build something that doesn't work
    75. 75. Choke on it
    76. 76. Some home truths ❽
    77. 77. The user is not the enemy If they don't understand it, that's your problem, not theirs.
    78. 78. The client is not the enemy If they don't like it, that's your problem, not theirs.
    79. 79. It may not go live Don't worry about it
    80. 80. Don't expect them to understand It's your job to understand it, not theirs.
    81. 81. "All the problems on this project were caused by this new CSS technology" circa 2008
    82. 82. ... that's all

    ×