maxgarrick.com

For the past 7 months I’ve been trying lean web application development for the MessageBoard project. Now that the project is complete, I thought I’d compare lean application development with the typical waterfall method. Many of these ideas came from the book Implementing Lean Software Development, which I highly recommend reading if you are used to a conventional waterfall development process.

1. Lean development constrains time, not scope
Plan to spend a fixed amount of time working on a set of functionality. If you overestimate what you can produce in that amount of time, don’t adjust the deadline–adjust the scope. I’ve taken out sorting, filtering, and other behavior to make a monthly release deadline. Note the missing behavior and bundle it for a subsequent iteration. At the end of each month, I’d reflect on what I did to over/underestimate, then learn and adjust going forward.

There are a few compelling benefits to constraining time over scope. Estimating, previously one of the hardest tasks for me to do accurately and important during end-of-year performance evaluations, became easier because I was always working with the same unit of time (one iteration is always one month). Scheduling Q/A and planning sessions time was straightforward since I was making my deadlines.

Constraining deadlines over scope results in better prioritization. I’ll start on the required functionality, saving nice-to-haves until the end. If I am approaching an end-of-month deadline, I’ll postpone (or eliminate, team willing) the least cost-effective functionality. I feel this has the effect of focusing staff time on the most valuable functionality.

2. Frequent reviews, lots of feedback
Transitioning from the design mockup to a working product is a big step where many usability and programmatic issues are discovered. Including Q/A and designer at the beginning and end of each month-long iteration saved time in the long run because these issues were discovered earlier in the implementation phase while the code was still flexible.

Having a designer writing HTML, CSS, and javascript code was also helpful. We invited our designer in the first Q/A session of each month, allowing Q/A to talk directly to the designer about user interface issues (wording, confusing behavior, potential support issues, etc….) I thought it was more effective for the two to communicate directly instead of interpreting and relaying messages between the two team members.

When releases are small and frequent, making minor course corrections becomes much easier. With the waterfall method, I wouldn’t see a designer or Q/A very much until major coding was completed. I’d receive a huge amount of feedback right at the worst time: when code was mostly complete, rigid, and changes were very error-prone. This feedback was more than just application bugs–it included UI and requirement changes. With our three person team frequently reviewing the product and communicating, we could quickly identify what needed to be changed (either due to oversight or a change in our perception of user needs) and then decide on a course of action.

Conclusion & Looking Forward
We’ve brought Q/A fully into the iterative development, next I’d like to see if bringing our design activities into the iterative process is more effective than completing the design mockups prior to coding. I think we’ve already seen the benefit of keeping the design flexible during implementation, allowing us to quickly make necessary UI changes. Perhaps with a solid requirements, a good roadmap, and some rough mockups this added flexibility will result in more usable applications. Keeping the design rough and more open to change could reduce some of the friction that comes when the team is reviewing “final” UI design documents.

effectiveness, lean development, messageboard, Q/A, waterfall model, web apps

MessageBoard, a PHP & MySQL web application with a Doctrine ORM back-end, was launched last Friday, right on deadline. This concludes 7 month-long phases of development.

I think the ingredients essential to delivering this application on-time and within budget were:

• Partnering with a user experience expert who designed the mock ups and wrote the bulk of HTML, CSS, and Javascript
• Doctrine ORM: previously we hand-crafted SQL which was error-prone and occasionally introduced security vulnerabilities.
• Month-long development iterations with a tested, working product delivered at the end of every month.

Looking forward, there is an increasing need at our campus for an Academic Personnel Review web application, which will transform a paper process into a fully online process. The major motivation behind this project is to reduce the massive amount of staff time that goes into coordinating this process in each campus unit.

This application will very likely be built in Java!

doctrine orm, lean development, messageboard, php

Just wanted to post an update to my previous blog entry about Doctrine ORM gotchas. Since 1.0.4 was released, a seriously limiting bug was fixed in the SoftDelete template. This bug was preventing typical performance optimizations that used LEFT JOINs to reduce the number of database queries. The idea is that a page generally loads much faster by executing few efficient JOIN’ed queries than many single-table queries (do your joins in MySQL, not PHP!)

I had posted a workaround to this bug ($query->addWhere(”deleted = 0 OR deleted IS NULL”) to all of your LEFT JOINs). This was cumbersome and I felt violated the principle of the SoftDelete event listener.

With this bug resolved, I’ve been more freely adding custom finders for specific pages. One page in particular (the MessageBoard thread index) went from 12 seconds to 4 seconds for a very large data set. The number of DB queries also was cut from 1200+ to about 300.

Now I just have to get the page down to 10 queries and we can call it optimized.

doctrine orm, performance, php, softdelete

Doctrine ORM is a PHP library that implements the ActiveRecord pattern we have all grown to love.  I’ve been using it for the past 7 months and feel it is one of the reasons we were able to deliver the MessageBoards web application on-time and within budget.

This doesn’t mean using Doctrine has been all flowers and sunshine: Doctrine will kick you in the face when you’re not paying attention.

Today I’d like to revisit all of those black eyes and bloody noses in the hope of helping fellow developers avoid the same missteps I made.  Doctrine is complex and quirky, and has some unanticipated architectural “features” that are not well documented.

Use Record::toArray() and Record::fromArray() to store/retrieve Doctrine objects from the session.

• Save space in the session store by adding only the column attributes of Record objects to the session.
• The session will quickly fill up otherwise, as Doctrine adds considerable bulk to model objects.

Improve performance by extending Doctrine_Table and implement custom DQL queries for complex and frequently used queries.

• If the controller or view will need a record’s related record, use a DQL query to join with the related table.

Optimize performance by getting to know and love Doctrine_Connection_Profiler.

• Add the connection listener at the beginning of execution and print SQL queries at the end of execution in order to identify areas of effective performance optimization.
• Example code that adds the listener and renders query events as HTML:

  
  // Set the connection listener
  
  $profiler = new Doctrine_Connection_Profiler();
  Doctrine_Manager::connection()->setListener($profiler);
  
  // Code goes here...
  
  // Render database connection events as HTML:
  
  $query_count = 0;
  $time = 0;
  echo "<table width='100%' border='1'>";
  foreach ( $profiler as $event ) {
      if ($event->getName() != 'execute') {
          continue;
      }
      $query_count++;
      echo "<tr>";
      $time += $event->getElapsedSecs() ;
      echo "<td>" . $event->getName() . "</td><td>" . sprintf ( "%f" , $event->getElapsedSecs() ) . "</td>";
      echo "<td>" . $event->getQuery() . "</td>" ;
      $params = $event->getParams() ;
      if ( ! empty ( $params ) ) {
            echo "<td>";
            echo join(', ', $params);
            echo "</td>";
      }
      echo "</tr>";
  }
  echo "</table>";
  echo "Total time: " . $time . ", query count: $query_count <br>\n ";
  

Effectively mitigate performance issues with memcache.

• The query and result cache can drastically offset Doctrine’s performance overhead.
• If you already have memcached running, this is one of the most cost-effective performance tweaks you can do.
• Note: I received mysterious fatal errors when using INDEXBY in DQL queries. After removing the INDEXBY, the errors stopped.

Play nice with fellow coders or testers by automating database migrations.

• Add a git merge hook that runs the Doctrine migration.
• Alternatively, check if a migration is needed on every page view while in development mode.

Play nice with other web applications by prefixing database tables.

• Set the table name prefix by calling $this->setTableName(’zzz_model_name’), where ‘zzz’ is the tool’s prefix.

Create a “resource-oriented” URL structure that closely follows the application’s models.

• This is borrowed from the RESTful architecture, and not necessarily Doctrine-specific.
• For example an HTTP GET on http://site.com/messageboard/m34/f11/ would display forum ID 11 in messageboard 34 in tool “messagebord”.

Use a workaround when using LEFT JOINs on models with actAs(’SoftDelete’) behavior.

• SoftDelete will automatically add the WHERE condition “deleted = 0″ to all queries.
• This prevents queries with LEFT JOIN from returning a row where “deleted IS NULL”.
• Either use INNER JOIN instead, or add the following to DQL queries: $query->andWhere(’deleted = 0 or deleted IS NULL’);

Timestampable cannot be disabled temporarily, causing challenges when importing data with dates.

• Doctrine provides no way to easily disable or override the timestamp behavior in order to import a pre-existing date.
• Until this behavior is resolved, try using this patch to set the ‘disabled’ option of Timestampable.

Use “cascade => array(’delete”)” to propagate soft deletes through model relations.

• The faster onDelete => ‘CASCADE’ performs the delete in MySQL, which does not set the deleted flag.

Put authorization code in one place, when possible.

Implement checkbox plus text input as two columns in a model.

• For example:
  Require password:
  
• This approach simplifies validation of optional attributes.

Use $model->setAttribute(Doctrine::ATTR_COLL_KEY, ‘id’) to key collections off of the primary key.

• If this attribute is not set, Collections will be indexed starting from 0 and counting upwards.
• This can simplify controller logic.

Use Doctrine_Pager only for the most basic views.

Use actAs(’NestedSet’) to model hierarchies that are read more frequently than written.

Use unix timestamps in Timestampable columns to ease formatting.

• Using a datetime works fine if the view never needs to change how a datetime is displayed.
• A unix timestamp allows for flexibly changing how dates are rendered, e.g.: “Jan 1st 2008″ or “Yesterday”.
• Example actAs() code:

  $this->actAs('Timestampable', array(
      'created' => array('name' => 'created_at',
          'type'    =>  'integer',
          'format'  =>  'U',
          'disabled' => false,
          'options' =>  array()),
      'updated' => array('name'    =>  'updated_at',
          'type'    =>  'integer',
          'format'  =>  'U',
          'disabled' => false,
          'options' =>  array())));
  

For multi-step forms, add a ’state’ column to aid in validating each step.

• In the model’s validate() function, use the state column to switch between validation logic.
• For instance, in state 1, validate columns a and b. In state 2, validate columns a, b, c, and d. In state 3, validate the complete object.

I hope this list saves some heartache on what is really a very elegant ActiveRecord implementation in PHP!

doctrine, performance, php, tips

MessageBoards, a redesign/rethinking of the EEE NoteBoard tool, will be coded by yours truly.

MessageBoards will provide board, forum, thread, and post-level functionality we have all grown to love–yet in the context of our academic portal tied into roster info.

I’d like to approach the way I code this tool differently, specifically:

• Introduce month-long design/code/QA iterations.
• Unit & integration testing.
• Create a good set of Selenium tests.
• Use the Doctrine framework for the underlying model.

Why bother changing the approach? We could code this tool just fine without changing the process, adding automated tests, and changing the framework.

MessageBoards is a big experiment. It may actually take longer to develop (although I hope not)–and it will give us a lot of good feedback on some new web development approaches that promise to reduce time to delivery. Delivering results faster–and with similar quality–would be a huge win.

There are a lot of variables in play, like the percent of time I dedicate to MessageBoards, and the four new approaches mentioned above. In the end, I anticipate it will be a challenge to isolate which variables added or removed value.

Another couple variables I bet will reduce time to delivery: working in parallel with a talented UI designer and the excitement of possibly finding something that will make other programmer’s lives easier.

effectiveness, messageboard, projects, web app, WorkLog