Talk given at the PHP Benelux conference in Antwerp, examining the points in the Joel Test and looking at how these suggested best practices apply to web development today
2. Who am I?
●
Lorna Mitchell
●
PHP Developer at Ibuildings
●
Editor at http://techportal.ibuildings.com
●
Host at DPC 2010
●
Personal site http://lornajane.net
●
Twitter: @lornajane
3. Who is Joel?
●
Joel Spolsky
●
Founder of Fog Creek Software
●
Blogs at http://joelonsoftware.com
●
Author of numerous books, particularly Best
Software Writing
●
Co-founder of http://stackoverflow.com
4. What is the Joel Test?
●
12 questions about your organisation
●
"... a highly irresponsible, sloppy test to rate the
quality of a software team"
●
Rule-of-thumb for best practice
●
How does it apply to PHP?
5. The Joel Test (1-6)
●
Do you use source control?
●
Can you make a build in one step?
●
Do you make daily builds?
●
Do you have a bug database?
●
Do you fix bugs before writing new code?
●
Do you have an up-to-date schedule?
6. The Joel Test (7-12)
●
Do you have a spec?
●
Do programmers have quiet working
conditions?
●
Do you use the best tools money can buy?
●
Do you have testers?
●
Do new candidates write code during their
interview?
●
Do you do hallway usability testing?
7. What is the Joel Test For?
●
Scoring your current organisation
●
Improving your current organisation
●
Scoring your next organisation
http://jobs.joelonsoftware.com
8.
9. Source Control
●
Central storage
●
Change history
●
Enables collaboration
●
Manage multiple versions
21. Deployment
●
Automated deployment
●
upload code
●
apply database patches
●
handle uploaded files and existing database
●
populate caches
●
switch over to new version
●
Automated rollback
22. Continuous Integration
●
A running process
●
Responds to commit (and/or hooks)
●
Performs tasks
●
No "forgetting" to run the tests
●
Gives feedback
31. Joel Says
●
Keep bugs near to zero
●
Cannot estimate bug fix time
●
Minimise unknowns
32. Capturing Bugs
●
As a minimum, record bug
●
Buggy behaviour
●
Expected behaviour
●
Smallest possible replication case
33. How to Report a Bug
http://tinyurl.com/8vx3s
●
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
if a computer does anything unexpected, freeze
Try to remember as much detail as
it's not worth reporting that the you can about what you were doing to
program generated an error it when it did fall over, and if you see
unless you can also report what any patterns, mention them. Anything
the error message was. you can provide has to be some help.
Some of the worst bug reports I've ever
seen come from programmers
34.
35.
36. Scheduling Workflow
collect
requirements
write separate into
specification discrete tasks
estimate task
duration
37. Who Estimates?
●
Ideally the do-er
●
At least someone who could do it
●
Never cut estimates
38. Specification
●
Holds the information needed for each task
●
May include acceptance criteria
●
More detail means fewer misunderstandings
●
mockups/pictures
●
form fields
39. Schedule
●
What each person is doing
●
When it is due to finish
●
Can record progress/actions
●
What is next
40. Agile and Timings
●
Agile development is reactive
●
Always on time at start of sprint
●
Estimates and spec detail can
be prepared per sprint
41. Burndown Charts
●
List of tasks
●
Tasks have estimates
●
Sprint is as many tasks as you have man-hours
61. Assessing Candidate Code
●
During interview
●
As part of recruitment process
●
Ibuildings uses this
●
The coding task makes a big impression on the
candidate
