Before I left college the only experience I had in software development was as a one-man team. I did all the design and back-end development. There wasn’t a conflict of interest between designer and programmer, because they were both one person! As I left college and got into the “real world” I found that it was impossible to do large-scale software development by oneself. All of the sudden there were information architects, program managers, user interface experts, database administrators, technical writers, and on and on.
I came to realize the value of specializing in one field. For instance, it would be counter-productive to mandate a DBA to learn Photoshop inside and out, and likewise it would be counter-productive to have the UI person learn how to know how to write every variation of database indexes. But I also saw the lack of knowledge that each had even of what the other team member’s responsibilities were that led to inefficient meetings, miscommunication between clients (especially in terms of requirements gathering), and overall it lead to a “that’s not my job” mentality that hurt the overall productivity of the team.
I believe we need address the lack of communication between the team members by increasing collaboration and at least a general knowledge of what the other is doing. If the programmer knows that the UI person is very concerned with Web standards then they can address that while he designs (among many other examples). All members of the team address the same client with the same requirements, and with knowledge of the various aspects of the SDLC the client can receive the maximum amount of value for their investment.
The article is broken up into examining the role and duties of the project manager and the developers. Both have unique responsibilities in order to ensure that the efficiency of the team is what it can be.
The Responsibility of the Project Manager
The responsibility of making this work falls on all members of the team, but the project manager (project lead, technical lead, etc.) is the one that has the authority to delegate who will work with who and for how long. There should also be a strong impetus for this person to embrace this ideology, because when conflicts arise between developers or between developers and clients the project manager is the one usually responsible for resolving the conflict.
By delegating developers to have a working knowledge of what the other members are doing through the software development and maintenance cycle then all members are able to offer constructive criticism to one another and help in a time of need. It is a great asset in the toolbox of delivering quality software.
Reduce Developer “Possession” of Code
I was sitting in a meeting, and when a customer bug request came up in a certain module then we automatically pointed to that one person who designed the module. The mentality behind it keeps other people on the team from double-checking the code and able to help each other of bug fixing and future development. Kent Beck, the popular proponent of eXtreme Programming (XP) (which I neither endorse nor discourage) says the following on “collective ownership.”
“One of the effects of collective ownership is that complex code does not live very long. Because everyone is used to looking all over the system, such code will be found sooner rather than later. And when it is found, someone will try and simplify it. […] Collective ownership also tends to spread knowledge of the system around the team.” (Kent Beck. Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series). New York: Addison-Wesley Professional, 2004.)
Regardless of whether one uses XP or another SDLC, the concepts introduced are a good starting point to increase the amount of communication between team members, increase productivity, reduce errors, and deliver higher levels of customer satisfaction.
Facilitate Team Briefings
We all love to talk about what we’re passionate about; so why not use that to the advantage of your team? I work on a team where the project lead encouraged us to give a briefing on a new technology or certain aspect of their job that would benefit other members of our team. Let’s use an example.
The user interface designer is constantly frustrated why the DBA and developers just don’t “get” web standards. It leads to conflict, because the developer is solely concerned about the function and not the form (in an extreme example). Well, why not let that designer brief the team on the value of web standards? It would also be helpful for that individual to outline best practices so the application has both maximum form and function. Often miscommunication happens over very small issues, and by taking the time to clearly outline a concept then the problem often goes away.
In fact, recently I gave a briefing to my development team introducing CSS and CSS best practices. Months of frustration on my part was alleviated as many members of the team started to see the business value of separating presentation from structure. We are now converting our old table layout to a CSS-driven layout.
Managing Many Egos
Let’s face it-designers and programmers have egos, and not just small egos but large egos. Everyone has their own philosophy on how development should be done; this is normally a good thing that brings variety and many perspectives, but sometimes it can also be a hindrance when trying to empathetically communicate with team members.
How many technical meetings have we all been in that seemed to go on and on and seemingly accomplish nothing? It seems like we spend most of the time debating philosophically on the best route which is perpetuated by our own individual ideologies. This can, and should be, alleviated by realizing that what’s best for the application isn’t always how we feel it should be.
The project manager has the added responsibility of ensuring that these debates don’t get out of hand by effectively managing the conversation and ensuring that every side is heard. Ultimately, every business decision that is made must be made by some superior who weighs the options and chooses the best. A manager that is open yet firm in making decision does wonders for moving development along.
The Role of the Developers
The project manager can do quite a bit to ensure to ensure that the team works in an optimized state, but ultimately it comes to the people that comprise the team-the developers. I want to give a few suggestions for the developers to ensure that cohesiveness is improved.
Everyone Should Test Everything
A great way to get team members to get involved with the entire project is to not relegate testing to individual projects or a singular tester. By involving all members of the team in testing helps ensure that the quality of the application will continue to increase. I am continually amazed at how members of my development team don’t even know how to use many aspects of the very application they develop. It is often the result of the “possession” of code problem address above.
Improved Knowledge Management
A good development team should be the most experienced and concerned about knowledge management. As the application matures then it becomes more and more necessary to ensure that correct and complete documentation is retained (although don’t wait to start). The great knowledge management challenge of capturing tacit (un-written) knowledge is critical to address when you’re in a development team. As developers come and go the need to be less reliant on one or two developers is extremely important. You should, at least in theory, have enough documentation to move developers around and if necessary to replace.
Fostering Mutual Respect
Aretha Franklin had the idea when she said: “All I’m askin’ / Is for a little respect”. We all love to know that we are respected by our peers, but it only comes about when we extend it to others. That whole Golden Rule idea is very applicable in this situation. When developers create an atmosphere where we respect one another and each other’s contributions then more efficient communication is likely to take place.
There are many ways to engage the entire development team, and the responsibility lies within the managers and the developers. It is truly a trial and error effort, but if you and your team seek to improve in the areas above then you are more likely to deliver a quality product to your customers and improve professional satisfaction.
Wait, aren’t all WordPress users writers? Well, not exactly. A lot of people use the WordPress platform to talk about their pets, family, or odd Star Trek fetish (which is fine); but there are users of WordPress who subject themselves the rigors of professional writing. This post really is for those wanting to improve their blog’s typography.
When I started my first blog I found that the more serious I took it and the more involved my posts got that I needed more functionality. I wanted my blog to look and act less like a blog and more like an online print journal. It was this desire that started my look for WordPress plugins that could address the desires I had, and these are the best.
The first thing I needed was a way to cite sources and make additional commentary in my writings, and footnotes are the perfect way to do that (even though they technically are endnotes, but the plugin does paginate). WP-Footnotes is an incredible plugin to accomplish this effectively. It has a lot of options, and it’s incredibly easy to use. You simply choose what the marking for the footnoted is (by default it’s double parenthesis), and when your post is rendered to the client it creates all the links for you.
A recent version has a smooth scrolling option that I do not like however. I instead plugged in another smooth scrolling script, and it turned out much better.
Table of Contents Generator
One of the things I enjoy about Wikipedia is how it can give you a quick glance at the article’s content through a table of contents. Generating this functionality in your WordPress posts happen through the Table of Contents Generator WordPress Plugin.
It has no need to use special markup like the ones above, because it automatically scans the headings in the posts and creates a table of contents. The plugin will also recognize top-level and sub-headings. It is a great reminder to use headings in your posts which drastically improves the semantic value of your content.
In Series WordPress Plugin
Often times when writing about a topic in-depth it’s advisable to break it up for the reader. The way to do this before would be to create a page announcing the series and provide links to all the articles in the series. Well no more! The In Series WordPress Plugin makes this task seamless. The plugin adds an option to add it to a series, and the plugin generates the necessary connections between the content. It’s great, because it requires no hacking of your template–it works right out of the box!
Even though I personally haven’t got to give this plugin a go, I’m excited to really make use of this one. Writing series is a great way to present lengthy content on the web, and this plugin takes all of the work out of doing so (besides the writing of course).
The last deals specifically with improving all the little things in typography that we traditionally miss but make a difference. This is a port from the original Python script for WordPress, and it carries the name WP-Typogrify. This does things such as inserting inline styles to adjust the CSS around all-caps, ampersands, and does important little things such as turning double hyphens into em-dashes and much more.