Development Process Beliefs

These are my beliefs and culture that back development process for product, project and support efforts. I’ve been specifically cultivating them since 2002.

Project Team

A project team of developers, QA tester, technical leader, and a dedicated client relations manager.

  • The team leader will be responsible for controlling the technical side of project running: responsible for taking technical decisions, analytical work, controlling of fulfillment of all tasks in accordance with technical specification, etc.
  • The client relations manager is in charge of controlling project running from the point of keeping deadlines, budget running, receiving updates or additional tasks, providing you with new estimations if necessary, reconciling of contracts with you, taking into consideration your ideas on improving cooperation way, etc.

Development Process


  • Improve developers today, to deliver better products tomorrow.
  • Manage projects like a business in micro-cycles, with long-term views.
  • Prioritize features, develop needs, and deliver a little extra.
  • Promote collaboration amongst all stake-holders.

Coding Standards

  • Teach them
  • Use them
  • Review them
  • Improve them
  • Self documenting code
  • Take pride in code

Software Development Methodologies

  • Team program
  • Extreme Programming and Agile Processes
  • Software Engineering Cycle
    • Analysis
    • Design
    • Coding
    • Testing
    • Delivery
    • Maintenance

Project Management

  • Task
    • No task greater than two weeks effort
    • Make big tasks into smaller tasks, preferably a day or two at most
    • Assignment
  • Twice weekly, half-hour progress stand-up meetings
    • Monday and Thursday mornings
    • Work day change up
  • Avoid working weekends and holidays
  • 10 AM to 6 PM or other likeable 8 hour block of time
  • 6 to 7 hours per day of development or training
  • Enforced breaks, meals
  • Code reviews
  • Process reviews
  • Pragmatic Teams and Processes
    • No broken windows – if it’s broken fix it
    • Boiled frogs – remain vigilant of the work environment and developemtn efforts
    • Communicate – team personality or identity, centralized external, free-flow internal
    • Don’t Repeat Yourself – project librarian
    • Orthoganality – organize around functionality, not job functions
    • Automation – if it’s done more than once, automate it – tests, scripts, templates, etc.

Code Goals

  • Stable
  • Reusable
  • Maintainable
  • Efficient
  • Generalized
  • Extendable
  • Quality and dependability over speed
  • Teams own the code, not the developer


  • Test first, code second
  • Release early, release often
  • Involve users in feedback often
  • If it’s broken, fix it
  • If it can be improved, do it
  • Refactor early, refactor often

Task States

  • New
  • Assigned
  • Do
  • QA
  • Approved
  • Release
  • Follow-up
  • Closed

Develop the Developers

  • Invest in our people
  • Teach developers to code more effectively
  • Pragmatic Programming Ideals
    • DRY – Don’t Repeat Yourself
    • Make learning a habit
    • Fix the problem, not the blame
    • Don’t assume it, prove it
    • Separate views from models
    • Test ruthlessly
    • Make it easy to reuse
    • Exceed user expectations
    • Sign your work
  • Developers that do well, matched with developers who don’t, but are willing to be open and learn
  • Have developers work with customer support to see clients usage and understanding of our products

Sample Project Team

  • 1 Customer Support rep
  • 1 Accounting rep
  • 1 Project manager
  • 1 Graphics design rep
  • 1 Network operations rep
  • 1 Senior management rep
  • 1 Client/end-user rep
  • 2 to 7 developers

Sample Development Area

  • Board table to sit all participants
  • 3 to 4 pair coding stations
  • White boards, markers
  • Scratch paper, pens
  • Water, coffee
  • Projector and screen


  • Minimums
    • Project Plan
    • Release Plan
    • Testing Plan
    • Release Sign-off
    • Product/Project Sign-off
  • Use Wiki or like to document:
    • Processes
    • Procedures
    • Developer guidelines
    • Desktop user guides
    • Project use cases
    • Project statuses
    • Project notes
  • Use PHP-Doc or like to document code

Morale Keeping

  • Query team on
    • Their interests
    • Own Ideas
    • Thoughts for improvement
    • What’s bad
    • What’s good
    • Value to company
    • Incentive
  • Review team code for
    • Good work
    • Improvement
    • Reuse
    • Examples of what to do
    • Examples of what not to do
  • Don’t let philosophy differences break teams
  • Teach different methodologies
  • Explain those that are actually used
  • Direct excess talents to side projects or outside contracts

Get Project Help from Aihrus