mLog

Valuable Lessons, Celebrations and Philosophy

Jump to content.
View Marcus Whitney's profile on LinkedIn Skype Me™!

www.flickr.com
This is a Flickr badge showing public photos from futuraworkz. Make your own badge here.

Click here to check out
The Barcamp Nashville Crew!

Credits

Truly Functional Specs

Ok. So, the folks at 37 Signals have posted their thoughts on functional spec docs, and interface driven software design. Being that I am currently studying as well as implementing this school of thought, I felt the need to give this post a whopping AMEN. Big-timer spec docs (SRS) add bloat to a project, and extra zeros to the budget of the customer with NO guarantee of an increased return on investment. This is a fact I’ve observed over and over in my software development history.

I’ve done several projects in the past where I was the only developer, and using a spec doc to communicate what I was going to do (no matter how detailed it was) never fully commnicated to the client what they were getting. Nor did it stop me from having to make revisions that were VERY painful because I was so glued to my spec doc. The spec doc alone is not sufficient.

This doesn’t mean that spec docs are useless.. on the contrary I think they are necessary for development teams to set limits and diirection for themselves. But when communicating the developent of software to a client, nothing quite brings the point home like an actual HTML mockup that they can see and click… even if the clicks don’t do anything. On the developer side, seeing a set of storyboards should help a developer to observe patterns and common widgets in the interface that could be made into reusable components in code.

Also.. let’s look at new ways of writing Software Requirements Docs. How about a little PHPDocumentor tutorial writing or JavaDoc class docblock writing? Can’t we stop taking extra time to write these huge MS Word docs, and start preparing our codebase with the requirements and contracts of the application so that we are quicker to implement or write the framework necessary to get where we need to go? I definitely think that unless you are writing a RFP (for Accenture or a company of it’s stature), 100 page Word docs to explain what you want an app to do may not be the most efficient use of your time. Especially when you think about the time you may need to spend editing the doc for the inevitable twists and turns that the software development process will take from Alpha to Beta to Gold.

A quick look at UML will tell you that the strategy that 37 Signals recommends for development is not that much different from the flow of modeling an OOP application using UML. Use cases come first, and use cases are flowcharts that are best visualized with storyboards initially. Out of a well defined use case, classes are developed.

Software architects must remember that while code is very technical, there is an aspect of design in every application. That design takes place at the code level, but also at the interface level. And, design and clients mean revisions. Wouldn’t you love to save yourself some time coding by going through a few UI revisions and walk throughs to get to a functionality that the client is pleased with. Of course… this doesn’t mean you won’t have revisions once the code behind the interface is installed. However, it does mean that you will have had a chance to envision the code behind the interface, and communicated any limitations or benefits you can see to the client. This can be incredibly valuable and a great time saver for you and you client.

My advise to coders, remember that clean code is only 1/3 of the battle. Client satisfaction and user experience are the overwhelming 2/3 of the equation that will always determine if your software development process is successful or not. Splitting your architecture efforts between a technical spec doc and a user interface/use case storyboard will make you more well rounded and a better developer in the eyes of your client.

, January 2008 August 2007 July 2007 June 2007 May 2007 April 2007 March 2007 January 2007 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 March 2006 February 2006 January 2006 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005

19 March 2005 comments [2] TrackBack-URI

Objectified PHP

So, what makes PHP 5 an official object oriented language now? Some say reflection, others say iterators. Type hinting is certainly a nice touch, and namespaces would make packaging much better. Truthfully… there isn’t anything that makes PHP 5 a more official OOP language than PHP4. All of the differences are in the new things that the language supports, but PHP 4 had the primary requirement: Classes . The same old PHP 4 objects run just fine in the Zend Engine 2, with maybe the exception of the way that ZE2 does pass-by-reference in functions and methods by default. In truth, PHP5 won’t be any more object oriented than PHP 4 if the developers don’t aspire to get a better understanding of the precepts and concepts of object oriented programming itself.

In many cases, that may mean venturing out of PHP into Java, C# and Python for the ways that object oriented programmers have been doing things with long term OOP languages for years now. This is a pretty far departure from a previous position that I held, which was that PHP is all I really needed to learn. This just isn’t true. I know that because I’m writing a PHP book now, and I know from my own research that PHP tutorials and books often share a certain school of thought. That thought being, objects are really no big deal.

When you consider the points that many PHP developers harp on… they may be right, in context. Performance is usually posed as a reason for staying object free. Development time is also an often touted reason. And then there are always the developers who haven’t learned design patterns yet and are simply having a hard time seeing the real advantage of methods over functions. All of these reasons are nice in theory, and work on simple applications that don’t require teams of 5 or more developers based on sheer scale alone.

This school of thought with a very light emphasis on software design has consistently been a weak point for the PHP community. PHP has too many popular and functional applications that have terrible software design and will eventually reach a point where they will either have to be rewritten, or they will be replaced with a much better designed application in the same product space.

This is gonna sound weird, but programming languages are almost like parents. Some languages are strict, and some are relaxed. Stricter parents often produce more disciplined, but boring children Relaxed parents often produce less disciplined yet interesting children. Java is a strict language that has produced many a disciplined, yet boring programmer. (Note: This is not an absolute rule, an elite programmer will excel and show creativity in even the most constrained development environment.) If Java is the uptight anal parent, then on the flipside, PHP is the overly-friendly, hippie parent. PHP has produced some incredibly creative, undisciplined coders. This is undeniable, and it’s the biggest problem facing PHP’s entry in the enterprise today. The enterprise will choose disciplined, boring code over exciting, chaotic code anyday. Again… not an absolute rule, but more often than not this is the case.

PHP programmers simply must become more knowledgable about programming in general, and object oriented programming in particular in order to make sense of the great new object model in PHP 5.

January 2008 August 2007 July 2007 June 2007 May 2007 April 2007 March 2007 January 2007 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 March 2006 February 2006 January 2006 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005