Leave a comment
Category: Growing Pains, Databases
Recently I posted the following question on LinkedIn:
I often come in to businesses or groups that are growing rapidly. In these situations it seems inevitable that there is someone who has been on the team a long time, has a monopoly on technical knowledge, and refuses to share his experience and knowledge with newer team members. Every bit of information sharing must be painfully argued, justified, and politicized; often taking days to get a simple 5 minute answer. Team members eventually begin avoiding this person whenever possible, spending hours tracking down simple answers, because the process of getting a simple answer is so difficult.
So how does one deal with this situation?
I received six answers (though no “magic bullet”) for dealing with such a situation. Most answers were combative, though one answer (number 3) was especially empathetic.
Answer 1: Tell the CEO
The first answer, and probably most natural one, suggested that the best way to deal with an Information Hoarder through authority:
Have your CEO or President give the person a good talking to or document how time would have been saved or new sales could have been generated if you had obtained the necessary information from this person on time and present it to the person & CEO/President. By then they should get the message.
Of course, attempting to sway authority can be difficult - even self defeating - when you are an outsider. There’s a good chance that the CEO knows and trusts the Information Hoarder, has successfully trusted him in the past, and has even had barbecues or family outings with him. To position yourself as a wedge between them seems counterproductive.
Answer 2: Force them
Information hoarders usually think it gives them power and if the company lets them get away with it, it does give them power. The best option is to deal with it directly and quickly. Force them to either become a team player or get marginalized as the team moves forward.
One option would be to require that person to document everything. Take him off other projects until the information is fully documented so someone else can pick it up and use it. Have other people review the documentation to make sure it is clear and complete. If information turns up later that was not documented and you need to go through the politics again, document the fact that the previous assignment was not completed satisfactorily in the person’s review. This will take away his power real quickly and put him on the defensive for his behavior.
This answer, like the first, attempts to use authority to get the Information Hoarder to submit. Unfortunately, such a solution does not work well unless you have the authority. Even if you do have the authority, as “the new guy” (or gal) it is generally important to encourage teamwork as opposed to discouraging the behavior of a long-standing team member. You run the risk of alienating a potentially valuable asset as well as setting a bad precedent.
Answer 3: Establish them as a guru
This answer from Philip Stanley is a long one, but is by far the best:
The answers received so far are somewhat combative and position a burden upon the information holder that is likely to be insupportable and at odds with the true extent of their knowledge - particularly around ideas in forcing the documenting of the knowledge they hold.
Their ability to retain information in depth and recall it accurately is the skill your team have already recognised as immensely valuable - the ability to map, organize and arrange the same depth of information in documentation to be useful to a team is not necessarily a skill this personality type would hold.
Whilst I appreciate the frustration, the net result of either course laid out so far is likely to be alienation, massive intellectual resistance and at worse, deliberate, subtle, misinformation.
Go a different way. Establish the person as a guru, an information god, an oracle. Make their ten words as valuable as 20 minutes and a page of notes. Involve them and enrapture them in the data, remove unnecessary complications and their day to day obligations and put them on high availability for the teams. Give them more overview, establish them as the domain owner and expert, and provide them with an assistant to marshal requests. Make sure that brain is invited into meetings and their opinion is sought.
Suggest and then help them prepare a series of ‘10 things you must know’, ‘10 things we _must_ avoid’, ‘10 ways -not- to spoil the project’ etc. bulletins for the team.
Pull them so far into the heart of things that there is simply nowhere else they want to be, make it easier for them to answer the ad hoc questions from a team because it is their recognised skill and function - reward them.
Stepping up a level, invent a new title (better than these
TECH (Technical Collaboration Head) GURU (General User Research and Understanding) and understand _their_ appreciation of the difference between giving, sharing, and collaborating.
Often collaborating is a option when the other two are not, because it is information acquisitive at the same time as information sharing; there is balanced input and output. You may need to reframe presentation of information need so it can be seen as being collaborative working.
Why on earth would one go to all this trouble, when a simple blast from the CEO is what everyone thinks they deserve? They’ve been there a long time, the firm is invested and the cost to release is high, perhaps prohibitive.
Better to take that mind and experience and help the owner find a new paradigm for involvement. Work your asset, rather than liquidating at below market value.
This answer reminds me of the old “embrace and extend” motto, but perhaps without the “exterminate” step. What I think perhaps that the first two answers were forgetting is that the Information Hoarder has been around a long time and is therefore likely to be incredibly valuable. Should not this person be rewarded for their value?
Answer 4: Start a Wiki
Answer 4 extends Answer 3 with some technology suggestions:
Take Philip’s excellent suggestion of the series of “10 Things” papers and put them on an internal Wiki. This will allow several positive things. First, it recognizes the person as an expert inside the community. Second, it allows other team members to add snippets of additional information so that you get a company repository rather than an “in the head” repository. Third, as the amount of other information increases, it pressures the information hoarder to share more to keep their position of expertise intact.
I think this is a great idea. Furthermore, creating a Wiki is something that can usually be done without authority. Even if embracing the Information Hoarder’s potential doesn’t work, a Wiki can be used to promote general collaboration and thereby at least mitigate some of the issues created.
Answer 5: Run over them with a bus (actually, just pretend like you did)
Alternatively - act like you would if that person was “run over by a bus”. Nobody is that important that the World would stop turning if they were no longer around. It also forces the rest of the team to think for themselves and not have an excuse for inactivity. Oh, and it takes the power away from the “hoarder”. I have successfully managed staff just like that!
Feel free to comment on this one yourself. I prefer to leave it alone.
Answer 6: Appeal to the ego, apply a process
There are two issues at work here:
1) You have one individual with a lot of “tribal knowledge” that resides nowhere else in the organization
2) The individual often feels that sharing knowledge puts his/her job at riskYou need to deal with both in order to have an effective fix. A senior manager or dept head should meet with the individual first and appeal to the ego - “Mary, you’ve been here a long time and you are such a great resource for us. I really need your help in training some of the less experienced staff members, etc.” Offer an incentive for a successful outcome - the ability to work on a fun new project, attend a seminar at a nice location, etc.
Now address #1 by documenting what this person knows so that knowledge can be easily transferred to others. Using ISO, six sigma, or another type of business process improvement can be a good mechanism for this, i.e., “Mary, we need to document this process for our upcoming ISO audit and I’d like you to take the lead on this.”
Establishing goals with measurable and specific outcomes will go a long way toward making this happen. Good luck!
Interestingly, this is the only answer to suggest that the Information Hoarder may fear for his or her job; a premise I felt was implicit in information hoarding. Easing this person’s fears may be all that’s needed to start the flow of information. And if not? Leave it to a well defined process, not an authority figure, to be the bad guy. Sounds like good advice.
Answer N: What do you have to say?
If you’ve ever dealt with a similar situation, how did you deal with it? Were you successful? Have you ever been an Information Hoarder? If so, what was your motivation and how could the cycle have been broken earlier? Will anyone even admit to it?
Leave a comment
Category: Growing Pains
Today I was reading about the medical practice of triaging and thinking about how it relates to software development. A software development triage is a common practice for projects in trouble. So how does one set-up a successful triage for their project?
What is a triage?
A triage is a way of rationing limited medical resources, typically in the event of a disaster. The purpose of a triage is not “normal” medical treatment, which seeks to help and heal everyone receiving treatment. A triage is setup to let people die by intentionally denying them treatment so that others more likely to survive can receive treatment. The result is a net gain in the number of lives saved.
What does this have to do with software development?
For a failing project, a triage is setup to let features, requirements, and bug fixes “die” so that others may be implemented. The importance of the task-at-hand is secondary to the probability of success.
This can sound counter-intuitive: Why would you complete less important tasks and let more important tasks die? Two reasons:
How does a software development triage work?
Just like with a medical triage, tasks are “tagged” to indicate their priority, based on their likelihood to succeed.
Once a triage is setup, it is important to constantly monitor it. Tasks “left to die” may receive the resources needed, and tasks that were once low risk may suddenly become high risk (if this happens often, consider a reverse triage).
Just as a medical triage consists of controversial and difficult ethical decisions, a software development triage will consist of similar business decisions. It is therefore a politically difficult thing to do, so be sure your project is truly in need.
Once the project is back on track, the triage should be ended and regular development should resume. Just be sure that “regular development” is not what created the need for a triage in the first place!
Leave a comment
Category: Best practices
Build automation is the foundation of continuous integration. Continuous integration helps to identify problems quickly - sometimes immediately - before they delay your project. Whether a continuous integration build is executed immediately upon check-in or scheduled to run nightly, at the heart of it lies the automated build process. (For an excellent, detailed article on continuous integration, see Continuous Integration on Martin Fowler’s website).
So how does one create an effective automated build process? Just like any other project, stay agile: start with fundamental tasks, then add complexity based on the needs of the project. Don’t get stuck creating the Ivory Tower of build processes.
The most fundamental steps of an automated build process are:
Between compile the code and report what happened, some choose to add deploy; however we’ll cover that in the next section, Baby Steps.
Get the code. Most version control tools, such as Subversion, are relatively easy to automate. Early versions of your build process will probably check-out the most recent version of the code from the trunk. However, as the process continues to develop, it may look to specific build branches in the version control repository or to specific revisions. Be sure that your script checks out all the code needed to successfully compile, including any shared libraries. If supporting shared libraries is too much of a chore, be sure to look into the practice of using externals (don’t just make copies of everything!).
Not using version control? Well you should be.
Compile the code. This is the most basic test of your code - if it doesn’t compile, it’s just text. When scripting this part of the process, keep in mind the correct build order, compiler options, and other switches (is this a debug, test, or release build?). For example, you probably want to enable detailed logging in test builds and probably always want to build the installation project last.
Report what happened. Some choose only to report errors, quipping “no news is good news.” This is true until you discover there was an error sending out error reports. So I recommend reporting everything that happens, even if it’s just to say “everything went well.” The report its self can be in the form of an email, an update to your projects Wiki, an entry in your tracking system, or all of the above. (To give an interesting example, I once saw a traffic light being used - red for complete failure, yellow for warnings, green for success).
Unless your project takes a long time to compile, these three basic steps probably won’t save you a lot of time. However, they do lay the groundwork for the more time-saving features that are further discussed below.
Once the basics are done there are a few simple, arguably fundamental, features that should be added to the process to save amazing amounts of time. Some of these essential tasks are:
Unit test. If you are, or want to be, an Agile team you have probably already implemented unit tests using JUnit, NUnit, or a similar framework. If you are not unit testing, pick up one on of the Pragmatic Unit Testing books to find out what you’re missing and how to correct the situation. If your unit tests are already automated via a framework, simply call them during the build process. Make sure to be aware of tests that will interfere with external environments and only call such tests when it is safe. The XUnit frameworks have ways of categorizing and tagging each test and groups of tests, so identifying the correct tests to execute should be an easy task.
Document. If you are using a tool such as Javadoc, NDoc, or SandCastle then your automated build process is the ideal time to extract documentation from your code. Documentation extraction can be a lengthy, boring process that utilizes a significant portion of your CPU so it’s great when it can be done automatically for you on another machine or at least while you’re away getting coffee.
Deploy. This can be as simple as copying files to a “latest version” directory or, as your build automation script evolves, can become a full-blown installation complete with test data generation. Better yet, several installations could be created to represent common [test] environments. In some instances “deploy” is actually a live deploy; I’ve most commonly seen this used for content-only updates to websites.
By now your build process should be helping out a lot: Developers are spending less time trouble-shooting and more time coding and QA is spending less time setting up environments and more time testing. So what next? Here are some ideas:
Expand what you already have. Just keep improving what’s there, adding a tweak here and a nudge there to the existing build process. Improve reporting by hooking up that traffic light or updating that dashboard. Expand testing by adding all of your automated test suites (stress tests, integration/system tests, etc.). Continue to improve the deployment process by introducing virtualization, generating random test data, or synchronizing development, test, and production environments.
Get the timing right. As you expand what you already have, the build process may begin to take too long. You will also notice that not everything your build process does needs to be done every time. This is the time to start separating out different “types” of builds, and executing them when necessary. For example, a unit-test build can probably run on every check-in or several times a day; however a build that runs stress tests may need to run nightly so that humans aren’t bothered by bogged-down systems. This may also be the time to move to a build-server if you haven’t already.
Enhance communications. Have your build-process update your project repositories (version control, task tracking, wiki, calendar, and so on) with information from the latest build. For example: if bug-fixes have a “Pending Build” status in your task tracking application, your build process should mark them as “built” and forward them on to QA for verification. For milestone builds, you may want to automatically tag the code. If three builds fail in a row, a meeting could be automatically scheduled. You could add a code churn report to the project wiki.
Get the idea?
From traffic lights and cha-ching! sounds to text-messages indicating that it’s been a week free of build failures and it’s time for pizza and beer; it’s OK to have some fun with your build process… and it’s much easier when that process is automated.
Leave a comment
Category: Best practices, Agile, Automation, Version Control, Quality Assurance, Continuous Integration
The following list of tools are useful for practically every software development project - onshore or offshore, distributed or local. Often, however, these tools are overlooked and a lot of time gets wasted trying to solve problems that could have been solved or mitigated by good tools. Let’s take a look at an overview of these time and headache saving tools. Follow-up articles will explore best practices about each tool more in depth.
Version Control
Imagine having a time machine for your project, allowing you to go back to any point and time and see exactly what the project looked like - the tests, the documentation, the code, the databases - everything. Even better, this time machine would let you change the past and investigate alternative futures by creating parallel time lines which could then be merged together! This is not fantasy or a scene from Back to the Future, it’s version control. It seems fundamental, but there are still many large software projects out there not using version control. Probably the best version control system available is Subversion.
Project Task Tracking Tools
How much smoother would your project be if bug reports, feature requests, and other “to do” items for your project suddenly stopped falling through the cracks? Stop scribbling notes on napkins and trying to sort through multitudes of email. Just put everything in one of the many (seemingly thousands) of well-design tracking system out there. A good tracking system can accept requests via email, allows assignment of tasks, and let’s you easily set priorities - even on multiple projects.
Test Automation Tools
Wouldn’t it be nice if, at the push of a button, you could execute every single test written for your project at super-human speed? While you went and got coffee? That’s what test automation tools can help you do. Of all the different categories of automated testing, unit testing is perhaps the most fundamental. Start there, and work your way up to more complex tests.
Build Automation Tools
Imagine always knowing, with confidence, how the changes from this week affected the changes from last week. Imagine if the latest features of your software were built and tested by the time you woke up each morning, before you even knew you’d have to give a demo that day. If you were making use of one or more good build automation tools, you could have that.
Wiki
Wikipedia has managed to document the majority of human knowledge in a vast online database. Case an point: every external link in this article is to Wikipedia. Wouldn’t it be nice if your project’s documentation was that good? If a bunch of anonymous internet users can do it, so can your team of professionals.
Comments (3)
Category: Best practices, Agile, Automation, Version Control, Quality Assurance
Is design dead? The short answer: no. The long answer is in this classic article by Martin Fowler. It covers misconceptions of where design practices fit into XP.
It’s a long article and if you need to read it but don’t have time, consider the irony that you do not have the time to read articles which will save you time. Then make time.
Some of the key points are:
Leave a comment
Category: Best practices, Agile
Communication issues abound in the corporate world. With offshoring, such problems can become exaggerated to the point of exasperation: Not only can you not work with your team face-to-face, but there are timezone differences, and language barriers can cause misunderstandings and frustration.
It does not have to be this way. Here are some simple tips to use when communicating with an offshore team. Combine them with other good communication strategies, and your offshore endeavors will be as efficient as any.
When on the phone… Speak slowly. Verify that the listener understands you. Enunciate. Try to minimize your accent if you have one. Some people have a tendency to shout when speaking to someone with an accent, try to avoid this.
When sending emails or IMs… Use good netiquette (don’t type in all CAPS, use excessive punctuation, etc). Be forgiving by assuming a helpful tone even if it is not apparent – it is probably cultural, not personal.
When instant messaging… Send complete sentences. Not. Fragmented. Messages. That. Must. Be. Pieced. Together.
When communicating requirements… Explain “what” and “why” – not “how” a feature should be implemented. Do not assume that the offshore team has the industry or internal system knowledge that your employees take for granted.
When asking for help… Often, offshore team members will make every effort possible to help you with an issue or to understand how something works. Do not over rely on the helpfulness of the team, as it does take away time from other duties. Make sure that any questions you have for them are complete, and well thought out.
In general… Be concise. Avoid idioms. There is typically no need to use simpler words. Do not be afraid to ask that a difficult sentence be reworded, and be patient if asked to do the same.
If you feel that “best” practices aren’t giving you the best results, you may want to consider bringing in a third-party to aid in identifying and solving problems with communication. Art of Progress has consultants available; email artofprogress@artofprogress.com for more information.
Comments (2)
Category: Best practices, Offshoring
There are many articles on adding
Ready? Here’s the secret: Use a ContentPlaceHolder. That’s it.
Try it for yourself. Here’s a code example:
<!-- Web.Master -->
<%@ Master Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
<title>Master Page</title>
<asp:ContentPlaceHolder runat="server" id="MetatagsContentPlaceholder">
<meta name="description"
content="This is the default description." />
<meta name="keywords"
content="keyword, keywords, key phrases" />
</asp:ContentPlaceHolder>
</head>
<body>
<asp:ContentPlaceHolder runat="server" ID="MainContentPlaceholder">
default content
</asp:ContentPlaceHolder>
</body>
<!--ExamplePage.aspx-->
<%@ Page Language="C#" MasterPageFile="~/Web.master" Title="Example Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MetatagsContentPlaceholder" Runat="Server">
<meta name="description"
content="Page-specific Description" />
<meta name="keywords"
content="keywords, for, this, page" />
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContentPlaceholder" Runat="Server">
You've got meta tags!
</asp:Content>
I think that the reason for the less straight-forward solutions is Visual Studio. When attempting the above in Visual Studio, the following error is reported:
Error 1 Unrecognized tag prefix or device filter 'asp'.
This led me, at first, to think that the solution won’t work. Of course, running the example works just fine and produces the following HTML code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="ctl00_Head1"><title>
Example Page
</title>
<meta name="description"
content="Page-specific Description" />
<meta name="keywords"
content="keywords, for, this, page" /></head>
<body>
You've got meta tags!
</body>
Leave a comment
Welcome to www.artofprogress.com, home of Art of progress LLC. While the initial place-holder for this site was up, we published the article How To: Use Meta Tags With ASP.NET Master Pages. Thanks to this article and Google, artofprogress.com was getting visitors from all over the world before it was even ready for prime-time!
This site is now powered by WordPress - a blog engine that does more than you probably think. This will allow us to easily make updates, syndicate content, and change the look of the site on a whim. Real Web 2.0 stuff. It also saves money to run everything on open source software: Linux, PHP, MySQL, and of course WordPress.
In the next few months, there will be new announcements, a new look, and an article or two on managing software projects.
Stay tuned.
Leave a comment
Category: Announcements