AGILE DEVELOPMENT
DESIGN PATTERNS
PAIR PROGRAMMING
REFACTORING
DOMAIN DRIVEN DESIGN
AMIABLE WORK SETUP
MAGNIFICIENT CALGARY DOWNTOWN
1) Our customers are on site.
2) Our requirements are expressed through stories - verbally
3) Our customers write acceptance tests
4) We code our tests before we write our code
5) We check in almost everyday - all your tests must pass for you to check in
6) We release frequently (daily to QA, monthly to the customer)
7) We do small slices of functionalty from end to end8.We have a product backlog
9) Our architecture and design is evolving
10) We haven't got one class or component called "Framework"
11) We have no single person who gloats themselves as specialists - ONLY general contributors! The collective code ownership, knowledge transfer is practised rigorously which gives me my 101 reason to love my job.
12)Stand up meetings: we don't book a room on intranet to setup a meeting. We have status meetings everyday which really helps you to stay focused, responsible and accountable. Nevertheless, all our meetings are mere standups at our respective work stations, more like a round table, everyday at 8.50AM, talking about yesterday's work, learnings, today's strategy and announcements. It is quick and very effective way, I believe.
DESIGN PATTERNS
Martin Fowler, the chief scientist at Thoughtworks is the deity.
Some of his ingenuously designed patterns we follow are
- Facade
- DTOs
- MVC
- Snapshot Pattern
- Domain Model Pattern
(We are strong proponents of intent revealing code and hence the long names of our methods,objects,variables and all and this eliminates the need to documentation. On the same lines, Joe was telling me that the reason we didn't resort to Java docs was to make the team spend more time on writing code than on updating the ever evolving classes' documentation in java docs.)
Here's an interesting article on "The bliss and bane of pair programming". We had an interesting discussion the other day on Pair Programming - a consequence of the tech leads blaming that our team ain't pairing up to the expectations.
My cut on Pair Programming
- Wonderful to implement the collective code ownership.
- Works splendidly when the pairs are on par. ->Augments Productivity astonishingly
- Enhances the Code quality with two pairs of eyes working on the code.
- Not advisable on an everyday basis - doesn't give time to contemplate
- Advisable for the partners to switch between the keyboards, since,The person typing thinks on tactical lines while the one watching more on strategic lines
- Not advisable 24/7 to newbies like me who can learn more by doing rather than watching.
- Lunches
- Dual monitors
- Loonie bin
- Open Door..aah! Are there doors at all?
- Virus Checkers
- Team Leads mind setup

more in the evening when i get home..............


No comments:
Post a Comment