Archive for the 'development' Category

Clean Models

Published November 2, 2009 development Leave a Comment
Tags: , ,

The flip side of what I said in my last post about Models in frameworks is that models shouldn’t know anything about the controller or view.  The data that the model is providing might eventually end up in JSON, or XML, or in a web page or HTML snippet, or in a CSV file.  None of that should matter to the model.

Generally models should not return error messages or “no data” messages that are intended for the eventual user, unless they are generic enough to be meaningful regardless of context.  It should always be obvious for the controller whether the call was successful, but the controller and view should handle how to display or send any messages.  Typically errors and other similar messages should be communicated through a central error or messaging handler.  The messages formatting and even content will vary quite a bit depending on how the results will eventually be delivered.

The data might be destined for a javascript heavy table, or for a CSV or Excel file, or a PDF file, or for a clean display on a light HTML page, or to pre-fill a form on a user’s return visit.  All of these will have very different formatting requirements, both for the data and for any messages that might get displayed to the user.  The deliveries that download files might actually never download anything if there’s no data, and might display messages in some other way.

Not building clean models, either by requiring that the controller know too much about the model, or by embedding information about the eventual delivery of the information in the model, is a recipe for spending time rewriting later, or for ending up with lots of duplicate code.

Models in frameworks

Published November 2, 2009 PHP , development Leave a Comment

One of my biggest frustrations with most MVC frameworks is that their approach to models are generally broken.  Models should hide the data from the controllers.  A controller shouldn’t need to know anything about the data, including what kind of storage is used.  Most frameworks don’t use this approach.

Suppose, for example, that I have a model for Users.  The model should provide the ability to add a User, remove a User, and update a User.  We’ll also probably need some methods for listing and other ways of manipulating the user information.  However, the model should be written in such a way that if we start with the user information in a database, and later move it to a remote LDAP server, or some SOAP or REST service, or a text file it won’t matter.  All of the controllers should be able to continue to call the same model methods that they were calling before, in the same way, and it shouldn’t matter to them where the data is coming from.  Knowing where the data is stored and how to get it and work with it is the model’s job.

This means that the model should not extend some database class.  The framework’s model structure should not assume that all models use databases.  In general, most discussions of MVC frameworks try to isolate the actual database work from the controllers, but they still require the controller to know too much about the data repository.  The effect is that you could probably move from a MySQL database to SQLite, but if you stop using a database entirely you are going to have some major work to do on your controllers that use that model.  To me, a major measure of success for any MVC approach is how much your controllers have to know about the data.  Less is better.

Zend Framework tries to accomplish this, but they basically do it by not giving you a start at any models at all.  Even if it was a very abstract class it would be nice to have something to extend.  At least that would give people a place to start that’s better than extending one of the DB classes, which just about all of the tutorials and articles on ZF models recommend doing.  ZF’s approach to just leave it entirely out of the framework means most instructions tell people to do it wrong.

I’m not a purist.  I’m a pragmatist.  I don’t care a great deal about patterns for their own sake, in any sort of Platonic sense.  I just want to be able to be lazy when I find out later that indeed change is normal and I need to adapt an application to shifting requirements.  Because as predictable as the weather in Phoenix, just about the time that an inventory application is just about through a couple of iterations and really getting useful, they are going to want to integrate it with some remote POS system, and oh yeah can it get its user information from some place in the cloud rather than the local accounts we wanted to use last week.  I’d much rather say “Sure, that’ll be ready day after tomorrow” than say “DOH!”  That requires the controller to be ignorant about the data repository.

Agile thinking for distributed teams

Published March 11, 2008 development 2 Comments
Tags:

Recent work changes have led me to think more intensely about development methodologies, project management for small teams, and similar issues, and I’ve been reading more about Agile development. I am much more interested in the philosophical underpinnings, the values of Agile, the overall approach of Agile development, than I am in the specific practices that make up a particular “official” methodology such as XP or Scrum. So I was interested to see Brian Marick’s post on his Exploration Through Example blog entitled “What is Agile? — beats me, but I know it when I see it“.

To me at my current stage of thinking, the most important components of Agile development include:

  • short release cycles with working software to the customer as often as practical
  • safety, trust and openness in the development team
  • frequent (almost constant) and informal interaction between members of the team
  • open communication between the user and the developers
  • transparency and visibility of information
  • focus on solving the business issues
  • adaptability
  • emphasis on the practical over the ideal, but always pushing for incrementally better
  • an attitude that fosters creative solutions, dedication to solving real problems, and ownership of the problems, process and solutions

I think that the Agile manifesto wraps a lot of this up. It embraces the following values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Reponding to change over following a plan

Agile processes focus on adapting to real needs, rather than trying to predict them and then sticking to the predictions regardless of how accurate they turn out to be. They focus on meeting the needs of people over the needs of the development process itself.

There is a lot in the various methodologies that is good, but to me the philosophy for development espoused by these ideas is what its about. Methodologies need to adapt to the situation, just as other components of planning and process must.

Most of the information I have come across in the “formal” Agile methodologies completely overlook or dismiss distributed teams. This is just not well connected to the real world. Instead of dismissing those of us who live in distributed teams (and the numbers are growing), we need ideas about how to reach the goals of Agile development in the reality we live in. That mostly means finding ways to work closely together, to have transparency, code review, collaborative approaches to working and coding, and high levels of interaction and trust in teams that might be physically together only rarely.

For me, the biggest component to success over the long term in development projects is in the relationships–in trust and open communication–between the members of the development team, between the developers and users and customers, and between the development team and management. If those are missing, things can quickly fall apart.  Building and maintaining these in distributed teams, and when the team is not local to the customer, is challenging.  The real world many of us live and work in day to day, the team, the boss, and the customer might be literally an ocean away.  In this world the values of Agile development that I outlined above hold just as true.  Its just the charts scribbled on paper, pair programming on one computer, and in person stand up meetings that do not.

Test first or test later

Published February 20, 2008 development Leave a Comment

A lot has been said about test driven development.  While I am a proponent of testing, I am not a fan of test driven development.  I could go on at length about it, but actually somebody else has already said it clearly, so here’s a link to what Paul M Jones said about it instead of boring everybody with a retelling here.  I’m pretty sure he’s smarter than I am anyway.