Find out interesting thoughts and experiences about the selection and usage of a frameworks for your projects in this set of slides ‘Living with Frameworks‘ by Stuart Herbert, Technical Manager at www.gradwell.com.

You will learn about:

• How frameworks save you time (=money) and ensure quality but can also waste resources if applied in another way the framework was intended to be used.
• The importance of the framework guru role.
• That a chosen framework and architecture should be strategically introduced (top-down).
• Introduction and proper use of a new framework has a steep learning curve.
• Legacy code and the parallel maintenance hassle.
• Refactor early, refactor often, perform regular code reviews with the framework guru.
• Frameworks will not fix bad practice (specification, quality, no training).
• Your framework should fit your overall development plan and practice.
• Training your staff in your framework is a means of building your team.
• Headcount on projects has increased, means more teamwork, organisation around needs to mature too.
• Importance of upgrades and backward compatibility.

I have just discovered the tools section of the Smashing Magazine with very interesting articles like these ones:

• 50 Extremely Useful PHP Tools
• 75 (Really) Useful JavaScript Techniques
• 15 Helpful In-Browser Web Development Tools
• 50 Useful Design Tools For Beautiful Web Typography
• 15 Useful Project Management Tools

And there are many more!

There are many essays and articles on ‘Planning Poker’ out there. So I do not need to repeat the principles here. By checking out the recommended links (and folloups and others from your own research) you need to understand the following:

• What a story point of a project looks like and how you generate those story points in advance. Remember, your estimation should include design, coding, testing and delivery. In Planning Poker it is your goal to come up with estimates to those those story points with your team.
• The process of how one story point is estimated using the Planning Poker card deck and how to narrow down your team members’ estimates through discussion of the ‘played’ estimates.
• The background of the card deck used and why there are such odd numers in it.
• The effect all this will have to your project and the team.

The important thing is not the single estimate as such, but rather the open discussion among the the team members in advance, the mix of different perspectives and the collection of confidence in the team’s estimates. If the team is not able to get confident for an estimate you better recheck the user story in question and clarify it - possibly again with the customer. The more confident the team in one estimate is (=no big spread in single estimates of the team members), the less unclear ‘assumptions’ have been made in the estimate itself. This, in the end, reduces the overall risk (friction and interruptions) during the actual project and most importantly makes your customer happy.

Recommended articles and links:

• Let’s Play Planning Poker!
• Planning Poker Cards For Everyone (Print your own cards!)
• Nils Haugen on Planning Poker (Video 13min)
• Planning Poker (Examples with and without Planning Poker)

VersionOne have published their 3rd Annual ‘State of Agile Development’ survey: Results are available on this page or as pdf.

Overview of topics covered:

• State of agile methods.
• Mix of participanting companies.
• Reasons for adopting agile methods.
• Concerns against it.
• Practices applied.
• Reasons for failures.
• Where agile creates value.
• What tools are used.

Inspired by an article at InfoQ (http://www.infoq.com/articles/better-best-practices) I discovered an interesting model, which explores the nature of learning in an interesting way: The Dreyfus Model for Skills Acquisition.

In essence it describes how people acquire skills over time, what supports them best in their progress and how they behave with their growing knowledge. Five levels are described:

• Novice - Needs to be told exactly what to do. Has very little understanding of the context to base decisions on. Wants frequent quick wins, needs regular feedback and reassuring messages. Learns best by abstract and context-free rules.
• Advanced beginner - Is familiar with the basic steps but still needs guidelines to follow. This is the stage at which a learner is most dangerous - he knows enough to think he knows a lot. Uses more sphisticated rules than a beginner. Treats all aspects with equal importance.
• Competent - The learner begins to understand his tasks and starts seeing longer term consequences. He can figure out a sequence of tasks in order to accomplish a goal. Learns best when given hierarchical goal-based targets accompanied by some rules. *
• Proficient - An ability to analyse a situation and seperate what is most important develops. The learner is experienced enough that solutions start to just appear and are seen in the wider context. The person can rely on his judgements. He follows higher-leveled maxims. Decision-making feels less labourous. Searches inspiration, loves challenges and is open to constant learning.
• Expert - Works mainly on intuition and is rarely wrong. Involves critical reflection on his intuitions, rather than goal-based planning. Loves to meet and exchange thoughts with other experts. Best practices are seen as a necessary evil. Does not rely on rules and maxims. Has a vision of what is possible.

* Most people don’t get beyond the competent level at most skills. Progression from Novice to Competent is linear. The model points out that one can become competent at something just by doing enough repetitions, but learners who want to reach beyond this point need to develop and maintain an active will to become proficient. It takes many years of dedicated effort to become an expert in a particular field.

Here you will find an application of the Dreyfus Model to software development with Ruby on Rails: http://pragmaticstudio.com/dreyfus

This set of slides by Daniel Naber from his talk at JAZOON07 provides a nice overview on the Apache projects Lucene, Solr and Nutch:

http://www.danielnaber.de/publications/jazoon07_naber.pdf

I came across a nice paper explaining best practices in using version control (Subversion) in multiple agile team projects. The lack of concept, clarity and existence of understandable rules often leads to confusion in teams I work in.

Regular merging down from the stable mainline (catch-up) and merge and copy up (publish) of stable features from develoment branches.

Here are some of the rules I found useful:

• Each branch (even the trunk) has an owner and a policy.
• Agree on a common definition of Done = releasable (means Unit tested and integration tested).
• Trunk is the Done branch, it should contain releasable code at any time.
• Branch policy = Unit tested code, new releasable features or bugfixes.
• Don’t combine different release cycles on a single branch.
• Create additional branches as seldom as possible. Only create a new branch when you have something you want to check in, and there is no existing branch that you can use without violating its branch policy.
• Whoever touches the trunk is responsible for ensuring that the whole trunk stays releasable - including all previous functionality.
• Synchronize your code with the work branch continuously (daily).
• Code conflicts and integration problems should be discovered as soon as possible.
• Resolve conflicts on the branch that is least stable. Whoever checks in first wins.
• Merge from your work branch to the trunk on a regular basis, for example whenever a story is done. Don’t wait until the end of the sprint.
• Merge down, copy up.

Flow of changes around the mainline of your project.

Taken from the paper “Agile version control with multiple teams” of Henrik Kniber which you should read if you are not already an expert in branching and tagging across teams.

Here is a good description how to use XDebug and PHPUnit to measure coverage of your codebase with unit-tests. In my case it gave me motivation to write more and even better tests in order to reach somewhere near 100% coverage.

Visit Matthew Weier O’Phinney’s Blogpost and complete your test suites.

My first shot looked like this:
phpunit --report _coverage/ FrameworkAllTests.php

In trying to be a productive developer, I sometimes think I am not writing enough code… But writing new code is actually only a slice of the game. Check out Oliver Steele’s model of the Programmers Food Pyramid:

http://osteele.com/archives/2008/01/programmers-pyramid

I love reading things like this: Top ten things ten years of professional software development has taught me

Summary:

• “Object orientation is much harder than you think”
• “The difficult part of software development is communication”
• “Learn to say no”
• “If everything is equally important, then nothing is important”
• “Don’t over-think a problem”
• “Dive really deep into something, but don’t get hung up”
• “Learn about the other parts of the software development machine”
• “Your colleagues are your best teachers”
• “It all comes down to working software”
• “Some people are assholes (…) Don’t take this too hard”

Another cool article: The Future of Software Development

Points:

• “Digg, del.icio.us, YouTube and other poster children of the new web era were developed by just a handful of programmers.”
• “(…) dynamic systems are not engineered, they evolve.”
• “Like living organisms, these systems are continuously reshaped to fit the dynamic landscape of changing requirements.”
• “Code is constantly changed to make sure we end up with the simplest, and best possible system that reflects our current needs.”
• “(…) it only takes a few good men (and/or women!). With a bit of discipline and a ton of passion, high quality engineers are able to put together systems of great complexity on their own.”
• “Equipped with a modern programming language, great libraries, and agile methods, a couple of smart guys in the garage can get things done much better and faster than an army of mediocre developers.”

I came accross a very interesting view of Richard Gabriel:
http://java.sun.com/features/2002/11/gabriel_qa.html

His points:

• “(…) because you can program well or poorly, and because most of it is creative (in that we don’t really know what we’re doing when we start out), my view is that we should train developers the way we train creative people like poets and artists.”
• “(…) what do people do when they’re being trained, for example, to get a Master of Fine Arts in poetry? They study great works of poetry. Do we do that in our software engineering disciplines? No. You don’t look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don’t look at their design. You don’t study the lives of great software designers. So, you don’t study the literature of the thing you’re trying to build.”

Richard Gabriels website: http://www.dreamsongs.com
There you can find more interesting articles and downloads:

• “Richard Hugo, the 20^th century poet and writing teacher wrote about the use of triggers in creative work. A trigger is any idea, scene, image, thought, sound, smell, or memory that by its ‘appearance’ in a mind causes that mind to create something. A trigger can end up being a metaphor, a reminder, a stepping stone, an association, or anything that sparks connections to the creative mind. Hugo almost goes so far as saying that all creativity is really just an ability and willingness to take up the thread a trigger provides.”

I am currently playing around with Solr. Here is a nice tutorial to get started:
http://www.xml.com/pub/a/2006/08/09/solr-indexing-xml-with-lucene-andrest.html

A more indepth article from IBM:

• http://www.ibm.com/developerworks/java/library/j-solr1/
• http://www.ibm.com/developerworks/web/library/j-solr2/

• Wiki about patterns in PHP: http://www.patternsforphp.com
• Article about OO and patterns in PHP5: http://www.informit.com/articles/article.aspx?p=381922

The last resource also contains lots of interesting chapters from current web development books of various topics.

I came across this interesting article by Peter Norvig - Teach Yourself Programming in Ten Years.
Here are the keypoints:

• “Write several significant programs, and learn from your successes and failures.”
• “Work with an experienced programmer and understand what it is like to live in that environment.”
• “In 3 days you might be able to learn the syntax” (…) “but you couldn’t learn much about how to use the syntax”
• “Researchers have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis” (…) “There appear to be no real shortcuts.”
• “Get interested in programming, and do some because it is fun.”
• “Talk to other programmers; read other programs. This is more important than any book or training course.”
• “The best kind of learning is learning by doing.”
• “The most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors.”
• “In any case, book learning alone won’t be enough.”
• “Be the best programmer on some projects; be the worst on some others. When you’re the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you’re the worst, you learn what the masters do, and you learn what they don’t like to do (because they make you do it for them).”
• ” Work on projects after other programmers.” (…) “See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain it after you.”
• ” Learn at least a half dozen programming languages.” (…) “You learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.”

Kevin Barnes and his amusing - slightly cynical - view on the software lifecycle.

Blogposts:

- “The code garden (an analogy that sucks less)”
‘Basically, code is like a garden. (…) Giving people a better analogy is one of the best ways to quickly change how they think about things.’

- Agile processes, are they killing our children?”
‘I doubt anyone could accurately diagram my development process. (…) Every line of code they don’t write is another line that can’t break.’

If you have asked yourself: When can you safely say you’re done writing unit tests. The answer lies in the ‘Cyclomatic Complexity’ of your code.

When you have written tests that exercise each possible path through your code, you are having a code coverage of 100%. For your unit-testing efforts this means: you’re done.

Thinking about your code in terms of ‘Cyclomatic Complexity’ as you write it may help you write more testable code.

A simple explanation: http://www.litfuel.net/plush/?postid=137

http://en.wikipedia.org/wiki/Cyclomatic_complexity