Managing complexity is the most important technical topic in software development.  In my view, it’s so important that Software’s Primary Technical Imperative has to be managing complexity … Once you understand that all other technical goals in software are secondary to managing complexity, many design considerations become straightforward.
Code Complete Second Edition - Steve McConnell (Chapter 5.2 Key Design Concepts)

It all comes back to maintainability of your codebase. This is something that I am constantly trying to get better at. Typically the majority of time spent in a web application is post initial production deployment. I would advocate that extra time up front to make those smart decisions will only mean quicker response times when bug fix and feature requests are coming in. The quicker response times are a direct result of managing complexity up front.

http://framework.zend.com/manual/en/coding-standard.html

This is a decision I don’t make lightly, and one that I have been toying with for a long time.  Do you have a particular set of standards you follow?

Horst Rittel and Melvin Webber defined a “wicked” problem as one that could be clearly defined only by solving it, or by solving part of it (1973).  The paradox implies, essentially, that you have to “solve” the problem once in order to clearly define it and then solve it again to create a solution that works.  This process has been motherhood and apple pie in software development for decades (Peters and Tripp 1976) … a dramatic example of such a wicked problem was the design of the original Tacoma Narrows bridge … This is a good example of a wicked problem because, until the bridge collapsed, its engineers didn’t know that aerodynamics needed to be considered to such an extent.  Only by building the bridge (solving the problem) could they learn about the additional consideration in the problem that allowed them to build another bridge that still stands.
Code Complete Second Edition - Steve McConnell (Chapter 5.1 Design Challenges)

Perhaps because I am a Mainer I keyed in on this content.  It’s wicked good!  At any rate, I like the example that McConnell uses to illustrate a wicked problem.  Imagine though that the bridge had not collapsed, and instead only violently swayed in the wind.  Would the engineers have taken down the bridge and started over, or would they have monkey patched tried to extend a flawed design?  Would the bridge have been easy to “fix”, or would the fixes only have introduced more potential for disaster.  It’s interesting to think of software in this regard.  It’s impossible to design software today that addresses every issue of tomorrow.  If the software is written in a cohesive, organized, thoughtful way though, it should be easier to monkey patch extend.

Currently Reading

Just in case you are curious, I am currently reading:

• Code Complete 2nd Edition (Loving every minute of it)
• Pro JavaScript Techniques (Great book)
• Stephen King - Firestarter (Just finished Bag of Bones 2 nights ago)

SELECT p.id, p.title FROM `pages` p WHERE
p.content REGEXP '(Â|Å|Ã)';

In the case of the above query, we’re just taking advantage of MySQL’s native REGEXP operator to check for the existence of any of the three characters (simplified for illustration) in a content block.  After running our SQL statement we quickly realized that the work necessary to clean this up would likely amount to at least a few weeks for our client.  With an additional few hours of work (after backing things up and testing, testing, testing) we were able to provide a solution that will take a matter of minutes to implement (if the client chooses to hire us to do so). Here is an abbreviated version of what we came up with:

UPDATE `pages` p SET p.content = replace(p.content,'â€Â','');
UPDATE `pages` p SET p.content = replace(p.content,'â€Å\“','');
UPDATE `pages` p SET p.content = replace(p.content,'¢â‚','');
UPDATE `pages` p SET p.content = replace(p.content,'¬Â','');
UPDATE `pages` p SET p.content = replace(p.content,'Â','');
UPDATE `pages` p SET p.content = replace(p.content,'¬Å\“','');
UPDATE `pages` p SET p.content = replace(p.content,'Å\“','');
UPDATE `pages` p SET p.content = replace(p.content,'Å','');
UPDATE `pages` p SET p.content = replace(p.content,'Ã','');
UPDATE `pages` p SET p.content = replace(p.content,'Å','');
UPDATE `pages` p SET p.content = replace(p.content,'¬','');

Conclusion

There isn’t anything earth shattering here.  These are simple queries, but they illustrate the inherent abilities of the technology employed with our client’s application.  These inherent abilities, if known, have the potential to save dozens of hours.  In the case of the above example, I truly believe we will likely save our client at least 30 man hours.

Top Frederick (as in Frederick, Maryland, USA) company looking for Senior Programmer …

I really, really wish I carried a camera in my car. How Senior is the person they are looking for I wonder? Senior in High School? I have a sense of humor, and this company was probably trying to appear casual and cool, but this just seems strange to me.

So, goodbye AF.  You have been a pain in my ass and you will not be missed.

Update: The surgery went well.  From what I’ve been told I was very hard to control on the operating table and had to be restrained.  At one point I sat up during the procedure and knocked my  head against one of the overhead devices.  There were 281 different burns made around my Pulmonary veins, and evidently I am a rarity, as I have 5 veins instead of the typical 4 (go me)!  I think the total time I was on the table was around 5 hours.  After my recovery period I was pretty sick due to the dose of anesthesia needed to keep me under.  Currenty I’m taking 5 different drugs, 2 of which are blood thinners.  I hate medication.  Lisa was awesome of course and is taking great care of me.  Her mom came into town to watch Cameron.  We’re so lucky to have her.  Anyway, my healing phase is 3 months, after which I hope to be drug free and free of AF.

The Client Needs Your Guidance

In most cases the client needs your guidance. If you want a consistent look for headers, lists, paragraphs, etc, than at a minimum you need to train the client in the use of your styles. If you want to reduce the amount of support requests you get, you should probably even include a style-guide.

As a sidenote, we are strongly considering including a developer docs directory in each site we build that includes a styleguide, as well as other relevant documentation. Putting client documentation under version control, in a protected directory, accessible via a URL is in our near future I think/hope.

Unfortunately it seems that this part of a project is often overlooked.

Stay Responsible

Developers tend to focus heavily on functionality and usability. These are important topics that need attention. I would argue that if you are giving a client a tool, and the tool is beautiful, and the tool is easy to use, you still have work to do. Clients want to be able to manage content, and most of the time that content is managed through a WYSIWYG editor (for instance in TinyMCE or fckEditor). The client needs to know how to properly use the tool, and it’s your job to deliver a responsible interface. When I say "use the tool" I’m really referring to the implementation of your styles, and not the ability to, for example, make text bold. Here’s an example of what I consider irresponsible:

	<div id="content">
		<div class="contentMainHeader">My Header</div>
		<div class="contentBody">Content Here</div>
	</div>

This type of implementation is irresponsible in a lot of ways. As far as the client goes, this markup introduces unnecessary complexity. It has been my experience that little things like this cause clients to bail on your intended style. This is the point where you usually start finding font tags and other craziness in content added by the client (might I recommend htmlPurifier if you really want things clean). Here is an example of what I would consider responsible:

	<div id="content">
		<h2>My Header</h2>
		<p>Content Here</p>
	</div>

Forgetting about the fact that our content now has more semantic meaning, your client should have an easier time populating content. Most clients understand the concept of a header and have an easier time with its application. As for the paragraph, both TinyMCE and fckEditor are going to create a paragraph by default (unless line breaks are not converted to paragraphs). In my experience this simple responsible markup can save a lot of time in support requests. In my experience the simple decision to use html tags as they were intended to be used can have a big payoff.

In Conclusion

Use markup responsibly and you will reap the benefits in many places. Your clients will be happier. Search engines will be happier. Your developers will be happier because they don’t need to wade through messy html. Remember, html tags are your friends and they have a purpose. Before you decide to create a class for everything under the sun, think about that tag you should be using, and scrap the unnecessary classes.

One of our clients at work has a site which is maintained with Dreamweaver (DW) templates and Contribute. If there is anything I have learned about this combination, especially DW templates, it’s that updating templates/libraries and pushing those updates to pages can become increasingly painful as a site grows. This particular client insisted on the template/Contribute route, and at the time we couldn’t make a solid argument about why they should not pursue this solution to content management (we now have that argument). We are on a maintenance contract with this client and once per week we have requests to update content. Because I did the initial setup, and because I have the most experience with DW, this job falls on my plate. Here’s the rough flow of data management / updates.

• We get a request to update the xxx section based on the yyy template.
• We checkout the xxx section pages, and the yyy template. Some sections have 100+ pages. In total this site has ~600 pages.
  • With each page checkout, DW performs a check to see if the page is already checked out.
  • DW checks the page out.
  • DW updates a lock file indicating that the pages is currently checked out.
• Templates/Libraries are updated and changes are pushed out to files.
• Files get checked back in (and locks are removed, etc)

This process is time consuming, slow at best, and very frustrating. Now I would normally be working on other tasks while files are being checked in/out, however that’s not the point. This whole workflow makes we want to vomit.

Today we had a request to add a footer to each page in the site, where previously there had been no footer. That’s an update for every template file, and every page in the site. You might be thinking, why didn’t you initially add markup for an empty footer, or at least add an include that pointed to an empty file? We didn’t, but that is a good idea. Instead, I took what would have amounted to 4 - 6 hours worth of mindless, brain numbing work (believe it or not, it would have taken 4 - 6 hours), and instead implemented a javascript/php include solution. This took about 10 minutes. Here is the markup.

$.get("/assets/php/includes/footer.inc.php", function(data){
   $("#wrap").after(data);
});

As you can see, I created a footer include file, used jQuery’s get method to retrieve the contents, and inserted those contents after the main wrapper div. I chose to pull the contents of the footer from an include file in order to make future updates of that content more manageable. I wouldn’t want a future developer pecking around in the JavaScript just to update the footer. That would be just plain wrong.

Conclusion

In the world of web development implementation typically isn’t the issue. Figuring out the proper solution usually takes more time. What I’ve done here isn’t rocket science, but it did save me hours of time, while not sacrificing future application maintenance. I can live with that.

code_swarm - Eclipse (short ver.) from Michael Ogawa on Vimeo.