Once again we are going to Kiev for Agile Eastern Europe Conference which will run this Autumn (8-9th October). Last edition was a great event and we expect this year to be even better. It’s enough to look at the speakers lineup, to be sure that Agile Eastern Europe once again will become a really international event:

• Mary POPPENDIECK (USA)
• Henrik KNIBERG (Sweden)
• Danko KOVATCH (Israel)
• Marc LOFFLER (Germany)
• Paul KLIPP (Poland)
• Anda ABRAMOVICI & Sudhindra RAO (USA)
• Robert DEMPSEY (USA)
• Vasco DUARTE (Finland)
• J.B. (Joe) RAINSBERGER (Canada)
• Mack ADAMS (Canada/France)
• Robin DYMOND (Canada/USA)
• Yves HANOULLE (Belgium/France)
• Monika KONIECZNY (Poland)
• Andrea HECK & Tibor VIDA (Germany & Hungary)
• Allan KELLY (UK)
• Dr. Johannes MAINUSCH (Germany)
• Sergey DMITRIEV (Norway)
• Piotr ZOLNIEREK (Poland)
• Sergei ANDRZEEVSKI (Russian Federation)
• Andrea PROVAGLIO (Italy)
• Pawel LIPINSKI (Poland)
• Nikita FILLIPOV (Russian Federation)
• Pavel GABRIEL (Belarus)
• Artem SERDYUK (Ukraine)
• Mikalai ALIMENKAU (Ukraine)
• Timofey YEVGRASHYN (Ukraine)
• Michael NORTON (USA)
• Pawel BRODZINSKI (Poland)
• Francois BACHMANN (Switzerland)
• Jurgen APPELO (Netherlands)
• Zsolt ZSUFFA (Hungary)
• Gwyn MORFEY & Laurie YOUNG (UK)

We are proud to be once again to support the conference as a Bronze Sponsor, so if you use tinyPM, think about using it, want to talk about the tool, it’s capabilities and your need, then Kiev will definitely be a place where you can push us to the wall and ask all the hard questions.

If you haven’t decided yet to come, go on and REGISTER now!

• Tweet This!
• Post on Google Buzz
• Add this to DZone
• Share this on Facebook
• Share this on Reddit
• Digg this!
• Share this on LinkedIn
• Share this on Technorati
• Share this on del.icio.us
• Share this on FriendFeed
• Add this to Mister Wong
• Submit this to Netvibes
• Add this to Ning
• Stumble upon something good? Share it on StumbleUpon
• Add this to Wykop!

How do you decide what tasks to schedule first: the complex ones or the easy ones? the short ones or the long ones? the risky ones or the sure-shot ones? Most often, this task sequence is determined by hard logic, soft logic, or some other external constraints. However, how do you decide when there are [...]

For my Remote Pair Programming session with Alexandru Bolboaca, I wanted to work on our actual code, not toy programs. It was hard finding a technical solution to allow this (despite the many suggestions I received on Twitter; the biggest issue is sharing the entire development environment), but I finally settled on LogMeIn. LogMeIn basically lets you create an ad hoc VPN with them serving as a middle man. The great thing with it is that all the configuration is done on the client machines. There is nothing to change on firewalls (especially important for the other people that you are working with).

LogMeIn has a download that seems very simple to use… as long as you are under Windows. It also has a Mac OS X version and a Linux version, but they hardly come with any documentation. What’s worse, it is hard to find additional information on the support site.

So, for your eyes only, here are some instructions on how to get LogMeIn to run under Linux. (this applies only to the client machine; setting up the network can be done entirely on LogMeIn’s website)

My configuration: Ubuntu 10.04 Lucid Lynx 64 bits with LogMeIn Hamachi 2.0.0.11-1. (Hamachi is a protocal that creates a VPN that goes through their servers)

1. First, create a login on http://www.logmein.com/
2. Install their Linux client. Just double-clicking it after download should be enough.
3. Configure the client in the command line :
   1. hamachi login
   2. hamachi attach <your email on logmein>
   3. hamachi set-nick <a human-readable user name for you; any should do>
   4. hamachi do-join <id of the VPN previously created on LogMeIn>
      • The password is the one specified by the domain creator. This is not the password for your login.
4. Wait for domain creator to approve your machine on the virtual network (you might need to send an email to remind her of that)

Done! From that point, you can use VNC or anything else to connect to a remote computer. Use something like ifconfig on the remote computer and use the IP address under the ham0 entry (ham is for Hamachi, obviously). The IP address has an unusual value such as 5.18.76.84.

You can read a book about agile development or Google any agile term, and the definition will most likely be in context of an engineering practice or reference to code. The basic concepts in marketing are very similar, but the ways they are implemented can be very different. Below are my translations.
 
Iteration/Sprint – A fixed period of time, usually 1-4 weeks, in which work is planned, managed and delivered. Agile teams commit to working on a set of prioritized stories and nothing else during this time period – nice in theory, not always possible in practice, especially in marketing.  In order to manage fire drills or other work, you can do one of two things – build time into your iteration, or get very disciplined at saying "We'll put it in the backlog".

Backlog – Prioritized list of work items (stories) not currently scheduled into the iteration. As you well know, marketing priorities are often changing (monthly, weekly, even daily) so backlog management can be challenging.

Story/Backlog Item /Feature – Most often in agile software development, it's code that delivers specific functionality and provides business value (What is a feature?). In marketing, the idea of business value still applies, but often times is thought of in terms of deliverables – collateral, online content, events, ads, etc.

User Story – A way to define a story from the perspective of the end user. The typical format is “As a (user) I want (requirement) so that (goal)”. This format works well to describe feature/functionality in software development practices, but we haven’t found it as useful on our marketing team. We structure our stories based on define, design or deploy phases (more to come on this later).

Estimation – The process teams use to determine the size of a story, usually through Story Points, ideal days or t-shirt sizes (small, medium, large, extra-large). The work associated with a story must be well defined/understood in order to accurately estimate. Keep in mind who outside of the marketing team is involved with a story -- even though you don’t include their time in the estimate, these stories usually take more time/effort.

Story Point – A unit of measurement used to estimate the work/effort/complexity of a story in order to give it a comparable size. Typically a 1 is twice as big as a 2 in terms of complexity. The challenge in marketing is that some stories might be “easy” but take a long time and others might be “hard” but not take very much time (more on this one too).

Task – The small, individual work items that comprise a story. Typical tasks in marketing include brainstorming, outlining, drafting, feedback loops, proofing, dry runs, pushing live, sending out.

Taskboard – A visual information radiator which is a fancy name for a whiteboard (physical or online), or wall chart with index cards, or sticky notes to track the status of tasks. Have fun creating a taskboard, but don’t over think it.

Defect – In agile software development, a defect or bug refers to an unexpected behavior in a feature often caused by a problem with the code. In marketing, defects are more likely to come in the form of typos, broken links, unclear messaging, etc.

Impediment – Anything that prevents agile teams from getting their work done. Common marketing impediments include too much feedback (often unsolicited), budget constraints, outside vendors and external dependencies.

Done – This deserves its own post (or even series of posts), but for now, done means that the tasks required to deliver the agreed upon value of a story are completed and the product owner has accepted the story. Life is much easier when done is defined at the time the story is planned and estimated.

These are only a few agile terms you’ll need to (re)define for a successful agile implementation in marketing. Have your own software-to-marketing agile translations? Please share.
 

How would you like to be able to SMS or tweet your Excel data-crunching code?

With Docjure, it is possible:

(->> (load-workbook "spreadsheet.xlsx")
     (select-sheet "Price List")
     (select-columns {:A :name, :B :price}))

This reads the A and B columns from the Price List sheet in the spreadsheet.xlsx file into a list of maps where the a column has key :name and the B column has key :price.

I believe that is pretty good for code small enough to fit in an SMS.

Exporting your business data to spreadsheets for further analysis is just as easy:

;; Create a spreadsheet and save it
(let [wb (create-workbook "Price List"
                          [["Name" "Price"]
                           ["Foo Widget" 100]
                           ["Bar Widget" 200]])
      sheet (select-sheet "Price List" wb)
      header-row (first (row-seq sheet))]
  (do
    (set-row-style! header-row (create-cell-style! wb {:background :yellow,
                                                       :font {:bold true}}))
    (save-workbook! "spreadsheet.xlsx" wb)))

In just a few lines of code and you have exported the price list to a worksheet, complete with a yellow-background bold header line for extra style points.

In our business applications, bridging to Excel has provided huge benefits:

• Users love it - having their data in Excel enables them to do much more than a static report that can only be changed by a software developer.
• Developers love it - It eliminates a lot of tedious code for generating bespoke reports as we can easily export data into an Excel report template.
• Project managers love it - using spreadsheets provides an easy to understand data exchange format and the flexibility to change reporting features quickly late in the project.
• Sponsors love it - the project saves a lot of time and reduces training cost by leveraging an application the users already know.

As an inspiration, here are some of the things we have used it for:

• Use Excel to calculate currency trading strategies - the traders calculate their currency trading strategies in Excel then import it into the trading system. They benefit from the flexibility of a powerful tool they already know and the trading system takes care of the technical details of the actual trades.
• Exporting to Excel for bespoke analysis - would you like to check your currency trading record? Export all the information to Excel and the traders can slice-and-dice it easily with little or no technical assitance. This is much easier than setting up a reporting database for them to link to.
• Using Excel sheets for content management to facilitate translation - translating an application to all the languages of an international enterprise was easy. Rather than using complex technical XML-files we made Excel sheets the data format for the application strings and had the subsidiaries add their translations to that. Then we put an adapter on the application to convert back and forth to XML-config files and RESX files used internally in the web and Silverlight parts of the application. The translators had a great experience, they had a familiar tool with spell checking and it reduced waste in the translation process by presenting a well-known easily accessible format.
• Exporting to Excel for reporting - set up a spreadsheet template with a data sheet and some reports based on that, then populate it with data from your application. This allows the users to easily change or add reports with no change to the software application itself, thus dramatically reducing the turn-around time for new reports. 

We believe this is so great that we just have to share it:

Therefore, Docjure is free and open-source.

It is written in Clojure for the JVM. Get it at our GitHub page here: http://github.com/ative/docjure and be sure to follow our updates on Twitter: @ativedk (http://twitter.com/ativedk)

It's fast, it's fun.  It powers your planning.  It tames your tickets.  It's the upgraded Agile Planner, our AJAX interface for adding tickets, building stories with tasks, and scheduling them into milestones, iterations, or releases.  For more details, please watch the video, or just select the “Agile Planner” link in the Tickets tool menu, and try it.

During the last year, many users have told me that they use the agile planner every week with their team.  So what is NEW in the Agile Planner this month? 

* It’s fast.  Drag and drop is smooth.  All tickets are loaded into local memory for instant access.  New layouts for “Milestone | Detail” and “Story | Detail” remove EVERY CLICK between mousover and seeing the detail edit form.

* Open tasks and subtasks to unlimited depth, in the Story/Feature column.  This “hierarchical ticket view” was one of our most requested features, with over 300 votes.

* Enter a list of tasks with the same attributes, using a new pop-up UI.

* In-place editing of estimates.  Just click on the number and edit.  The estimates add up correctly for complete features or milestones.

Incremental development is important

The Agile planner will help you with roadmapping, which I described in my article "Save the best for first".  It's a simple way to get what you want, fast, using incremental development.  We write down everything we want to do, and then we sort it by priority, and we try to find the minimum set of high-priority stuff that will get us a great release as soon as possible. 

A whole industry has grown up around incremental development, represented by Agile, minimum releasable product, lean startups, and even behemoths like Linux, which started as a student project. 

Sometimes, a planning view can be one of the biggest obstacles to this process.  If you write a view of your project that shows a feature listed under a milestone or release, and subtasks for that feature, it starts to force you into thinking that you need to finish everything before you can release.  You start to forget that you are in charge, and that you can release a simple version before you release the complete version.  In the Agile Planner, we separate the your grand plan in the Story/Feature view, from the schedule in the Milestones view.

How can you use the Agile Planner?

Use it with a client or business owner to launch a project.  It’s fun to see a plan take shape, which builds the relationship.  If you run a good roadmapping session, you get a big head start on the implementation, which is the biggest revenue earner. 

Use it with your team to plan iterations.  Many Assembla users sit down as a group with the agile planner each week or each month.  I have seen distributed teams do this with screen sharing tools.

Distribute planning.  I like to create a top-level story, and then ask the developer to fill in more detailed tasks.  It makes the developer feel more confident, and it makes the work more visible.

Many of our users like to sort their tasks into a very specific order.  Agile Planner gives you that control.

 

Here's a quick video of the Agile Planner, so you can see it in action.

by BILL WADDELL

In a couple of news items of note ...

Amazing But True

A guy by the name of Chuck Fellows is a candidate for the Michigan state senate.  Among the issues that have Michigan voters agitated this year is some controversy over giving tax credits to the film industry.  When asked for his thoughts on the matter, Fellows replied, "I want to see a cash flow statement and a value stream map of the process before taking a position. My ‘gut’ tells me it brings jobs and positive attention to the state." Now there are lots of consultants and employees working on lean in government, but this is the first time I have heard an elected official talking about value stream mapping a process to determine its effectiveness.  It is not quite as remarkable as it might seem, however.  Fellows has only been a politician for a couple of years, following 34 years in production management at Ford.  Maybe we need to start sending more Ford folks to capitols.

Leopards Can't Change Their Spots

I have noted a Wall Street Journal story a couple of times over the last year in which a young lady was none too happy to find out that P&G was putting the same shampoo they sold for $5 in a prettier bottle, hyping it up with their brand management voodoo as something marvelous, and selling it to her for $17.   Since then, P&G has come out with a diaper innovation called Dry Max.  Only it seems lots of mothers believe the chemistry in the diapers is bad and the Dry Max diapers are causing serious burns and rashes.  True to form, P&G opted not to change the chemistry, trashing the young mothers as crackpots who know little about babies and diapers, and instead, came out with a designer series of Dry Max.  Same diaper inside, but with stripes, plaids and ruffles on the outside - which they sell for $6 a box more.  A more cynical observer than I might suggest that flaming rectums cloaked in designer wrappings fits P&G well.  However I will leave it at saying P&G needs to learn from the lean world and start paying more attention to value and less to image.

Those Happy Cows

Last Fall I wrote of the Ethnicity of Cows, suggesting that the cattle in Happy Cow ads from the California Milk Advisory Board ought to be from California, rather than New Zealand.  Ms Jennifer Giambroni from that august group wrote an eloquent response to my post.   The California State Assembly, however, isn't buying it and saw things my way. In May they overwhelming struck a blow for the rights of California bovine screen talent, and from here on out all of the cattle in the ads will have to actually be California cows.

Somebody Oughta Do Somethin'

Summoning all of the vision, courage and statesmanship which has become the hallmark of the US Congress, the House of Representatives passed major sections of the 'Make It In America' act the other day to do their part in bolstering American manufacturing.  Nancy Pelosi's bill (1) says manufacturing's woes are all George Bush's fault, (2) says we need a strategy, (3) says clean energy is a good thing, (4) calls for establishing a commission to study the problem, (4) says we ought to put American flag logos on farm products, (5) says we should restudy the problem every four years, and (6) says the President should come up with a plan. All of American manufacturing can exhale, and certainly sleep better now that Congress has demonstrated such a clear sense of purpose and resolve to get us back on track.

That's it for now ... enjoy the weekend

30 Jul 2010 James Shore/Agile-Book

• Next: Continuous Integration
• Previous: Version Control
• Up: Chapter 7: Releasing

in 99 words

Build, test, and deploy your entire product at any time with the push of a button.

Your build should be comprehensive but not complex. Make it compile source code, run tests, configure registry settings, initialize database schemas, set up web servers, launch processes, build installers, and deploy. Your IDE won't do all this, so learn to use a dedicated build tool. Make sure your build works when disconnected from the network, too.

Builds should be fast. If not, look at your tests. End-to-end integration tests are the typical culprit. Replace them with faster, more maintainable unit tests.

as haiku

--> Commentary

Living in the Punch Card Era

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright &copy 2008 the authors. All rights reserved.

Ten-Minute Build

Audience

Programmers

We eliminate build and configuration hassles.

Here's an ideal to strive for. Imagine that you've just hired a new programmer. On the programmer's first day, you walk him over to the shiny new computer you just added to your open workspace.

"We've found that keeping everything in version control and having a really great automated build makes us a lot faster," you say. "Here, I'll show you. This computer is new, so it doesn't have any of our stuff on it yet."

You sit down together. "Okay, go ahead and check out the source tree." You walk him through the process and the source tree starts downloading. "This will take a while because we have all of our build tools and libraries in version control, too," you say. "Don't worry—like any good version control system, it brings down changes, so it's only slow the first time. We keep tools and libraries in version control because it allows us to update them easily. Come on, let me show you around the office while it downloads."

After giving him the tour, you come back. "Good, it's finished," you say. "Now, watch this—this is my favorite part. Go to the root of the source tree and type build."

The new programmer complies, then watches as build information flies by. "It's not just building the source code," you explain. "We have a complex application that requires a web server, multiple web services, and several databases. In the past, when we hired a new programmer, he would spend his first couple of weeks just configuring his workstation. Test environments were even worse. We used to idle the whole team for days while we wrestled with problems in the test environment. Even when the environment worked, we all had to share one environment and we couldn't run tests at the same time.

"All that has changed. We've automated all of our setup. Anybody can build and run all of the tests on their own machine, any time they want. I could even disconnect from the network right now and it would keep building. The build script is doing everything: it's configuring a local web server, initializing a local database... everything.

"Ah! It's almost done. It's built the app and configured the services. Now it's running the tests. This part used to be really slow, but we've made it much faster lately by improving our unit tests so we could get rid of our end-to-end tests."

Suddenly, everything stops. The cursor blinks quietly. At the bottom of the console is a message: BUILD SUCCESSFUL.

"That's it," you say proudly. "Everything works. I have so much confidence in our build and tests that I could take this and install it on our production servers today. In fact, we could do that right now, if we wanted to, just by giving our build a different command.

"You're going to enjoy working here." You give the new programmer a friendly smile. "It used to be hell getting even the simplest things done. Now, it's like butter. Everything just works."

Automate Your Build

What if you could build and test your entire product—or create a deployment package—at any time, just by pushing a button? How much easier would that make your life?

Producing a build is often a frustrating and lengthy experience. This frustration can spill over to the rest of your work. "Can we release the software?" "With a few days of work." "Does the software work?" "My piece does, but I can't build everything." "Is the demo ready?" "We ran into a problem with the build—tell everyone to come back in an hour."

Automating your build is one of the easiest ways to improve morale and increase productivity.

Sadly, build automation is easy to overlook in the rush to finish features. If you don't have an automated build, start working on one now. It's one of the easiest things you can do to make your life better.

How to Automate

There are plenty of useful build tools available, depending on your platform and choice of language. If you're using Java, take a look at Ant. In .NET, NAnt and MSBuild are popular. Make is the old standby for C and C++. Perl, Python, and Ruby each have their preferred build tools as well.

Your build should be comprehensive but not complex. In addition to compiling your source code and running tests, it should configure registry settings, initialize database schemas, set up web servers, launch processes—everything you need to build and test your software from scratch without human intervention. Once you get the basics working, add the ability to create a production release, either by creating an install file or actually deploying to servers.

Construct your build so that it provides a single, unambiguous result: SUCCESS or FAILURE. You will run the build dozens of times per day. Manual checks are slow, error-prone, and—after the umpteenth time—seriously annoying.

You should be able to build even when disconnected from the network.

A key component of a successful automated build is the local build. A local build will allow you to build and test at any time without worrying about other people's activities. You'll do this every few minutes in XP, so independence is important. It will also make your builds run faster.

Be cautious of IDEs and other tools that promise to manage your build automatically. Their capability often begins and ends with compiling source code. Instead, take control of your build script. Take the time to understand exactly how and why it works and when to change it. Rather than starting with a pre-made template, you might be better off creating a completely new script. You'll learn more, and you'll be able to eliminate the complexity a generic script adds.

The details are up to you. In my build scripts, I prefer to have all auto-generated content go into a single directory called build/. The output of each major step (such as compiling source code, running tests, collating files into a release, or building a release package) goes into a separate directory under build/. This structure allows me to inspect the results of the build process and—if anything goes wrong—wipe the slate clean and start over.

When to Automate

At the start of the project, in the very first iteration, set up a bare-bones build system. The goal of this first iteration is to produce the simplest possible product that exercises your entire system. That includes delivering a working—if minimal—product to stakeholders.

Use the build script to configure the integration machine. Don't configure it manually.

Because the product is so small and simple at this stage, creating a high-quality automated build is easy. Don't try to cover all of the possible build scenarios you need in the future. Just make sure that you can build, test, and deploy this one simple product—even if it does little more than "Hello, world!" At this stage, deployment might be as simple as creating a .zip file.

Ally

Continuous Integration

Once you have the seed of your build script, it's easy to improve. Every iteration, as you add features that require more out of your build, improve your script. Use your build script every time you integrate. To make sure it stays up-to-date, never configure the integration machine manually. If you find that something needs configuration, modify the build script to configure it for you.

Automating Legacy Projects

If you want to add a build script to an existing system, I have good news and bad news. The good news is that creating a comprehensive build script is one of the easiest ways to improve your life. The bad news is that you probably have a bunch of technical debt to pay off, so it won't happen overnight.

As with any agile plan, the best approach is to work in small stages that provide value as soon as possible. If you have a particularly complex system with lots of components, work on one component at a time, starting with the one that's most error-prone or frustrating to build manually.

Once you've picked the right component to automate, start by getting it to compile. That's usually an easy step, and it allows you to make progress right away.

Next, add the ability to run unit tests and make sure they pass. You probably compile and run unit tests in your IDE already, so this may not seem like a big improvement. Stick with it; making your build script able to prove itself is an important step. You won't have to check the results manually any more.

Your next step depends on what's causing you the most grief. What is the most annoying thing about your current build process? What configuration issue springs up to waste a few hours every week? Automate that. Repeat with the next-biggest annoyance until you have automated everything. Once you've finished this, congratulations! You've eliminated all of your build annoyances. You're ahead of most teams: you have a good build script.

Now it's time to make a great build script. Take a look at how you deploy. Do you create a release package such as an installer, or do you deploy directly to the production servers? Either way, start automating the biggest annoyances in your deployment process, one at a time. As before, repeat with the next-biggest annoyance until you run out of nits to pick.

This won't happen overnight, but try to make progress every week. If you can solve one annoyance every week, no matter how small, you'll see noticeable improvement within a month. As you work on other things, try not to add new debt. Include all new work in the build script from the beginning.

Ten Minutes or Less

A great build script puts your team way ahead of most software teams. After you get over the rush of being able to build the whole system any time you want, you'll probably notice something new: the build is slow.

With continuous integration, you integrate every few hours. Each integration involves two builds: one on your machine and one on the integration machine. You need to wait for both builds to finish before continuing on because you can never let the build break in XP. If the build breaks, you have to roll back your changes.

A ten-minute build leads to a twenty-minute integration cycle. That's a pretty long delay. I prefer a ten or fifteen-minute integration cycle. That's about the right amount of time to stretch my legs, get some coffee, and talk over our work with my pairing partner.

The easiest way to keep the build under five minutes (with a ten-minute maximum) is to keep the build times down from the beginning. One team I worked with started to look for ways to speed up the build whenever it exceeded 100 seconds.

Many new XP teams make the mistake of letting their build get too long. If you're in that boat, don't worry. You can fix long build times in the same agile way you fix all technical debt: piece by piece, focusing on making useful progress at each step.

Slow tests are the most common cause of slow builds.

For most teams, their tests are the source of a slow build. Usually it's because their tests aren't focused enough. Look for common problems: are you writing end-to-end tests when you should be writing unit tests and integration tests? Do your unit tests talk to a database, network, or file system?

Ally

Test-Driven Development

You should be able to run about 100 unit tests per second. Unit tests should comprise the majority of your tests. A fraction (less than ten percent) should be integration tests, which check that two components synchronize properly. When the rest of your tests provide good coverage, only a handful—if any—need to be end-to-end tests. See Test-Driven Development in Chapter 9 for more information.

Although tests are the most common cause of slow builds, if compilation speed becomes a problem, consider optimizing code layout or using a compilation cache or incremental compilation. You could also use a distributed compilation system or take the best machine available for use as the build master. Don't forget to take advantage of the dependency evaluation features of your build tool: you don't need to rebuild things that haven't changed.

In the worst-case scenario, you may need to split your build into a "fast" build that you run frequently and a "slow" build that an integration server runs when you check in (see Continuous Integration later in this chapter). Be careful—this approach leads to more build failures than a single, fast build. Keep working on making your build faster.

Questions Who's responsible for maintaining the build script?

Ally

Collective Code Ownership

All of the programmers are responsible for maintaining the script. As the codebase evolves, the build script should evolve with it.

At first, one person will probably be more knowledgeable about the script than others. When you need to update the script, pair with this person and learn all you can.

The build script is the center of your project automation universe. The more you know about how to automate your builds, the easier your life will become and the faster you'll be able to get work done.

We have a configuration management (CM) department that's responsible for maintaining our builds. We aren't allowed to modify the script ourselves. What do we do?

You need to be able to update your scripts continuously to meet your specific needs. It's unlikely that anybody can be more responsive to your needs than you are. If the CM department is a bottleneck, ask your project manager for help. He may be able to give you control over the scripts.

Alternatively, you might be able to use a two-stage build in which you run your own scripts privately before handing control over to the CM department.

How do we find time to improve our build?

Ally

Slack

Improving your build directly improves your productivity and quality of life. It's important enough to include in every iteration as part of your everyday work. The best way to do this is to include enough slack in your iteration for taking care of technical debt such as slow builds. If a particular story will require changes to the build script, include that time in your story estimate.

Should we really keep all of our tools and libraries in version control?

Yes, as much as possible. See Version Control earlier in this chapter for details.

Does the build have to be under ten minutes? We're at eleven.

Ten minutes is a good rule of thumb. Your build is too long when pairs move on to other tasks before the integration cycle completes.

We use an IDE with an integrated build system. How can we automate our build process?

Many IDEs use an underlying build script that you can control. If not, you may be better off using a different IDE. Your other alternative is to have a separate command line-based build system, such as Ant, NAnt, or make. You risk duplicating information about dependencies, but sometimes that cost is worthwhile.

We have different target and development environments. How do we make this build work?

If possible, use a cross compiler. If that doesn't work, consider using a cross-platform build tool. The benefits of testing the build on your development platform outweigh the initial work in creating a portable system.

How can we build our entire product when we rely on third-party software and hardware?

Even if your product relies on yet-to-be-built custom hardware or unavailable third-party systems, you still need to build and test your part of the product. If you don't, you'll discover a ton of integration and bug-fixing work when the system becomes available.

A common solution for this scenario is to build a simulator for the missing system, which allows you to build integration tests. When the missing system becomes available, the integration tests help you determine if the assumptions you built into the simulator were correct.

Missing components add risk to your project, so try to get your hands on a test system as soon as possible.

How often should we build from scratch?

At least once per iteration. Building from scratch is often much slower than an incremental build, so it depends on how fast the build is and how good your build system is. If you don't trust your build system, build from scratch more often. You can set up a smoke-testing system that builds the project from scratch on every check-in.

My preference is to reduce build times so that incremental builds are unnecessary, or to fix the bugs in the build system so I trust the incremental builds. Even so, I prefer to build from scratch before delivering to customers.

Results

With a good automated build, you can build a release any time you want. When somebody new joins the team, or when you need to wipe a workstation and start fresh, it's a simple matter of downloading the latest code from the repository and running the build.

When your build is fast and well-automated, you build and test the whole system more frequently. You catch bugs earlier and, as a result, spend less time debugging. You integrate your software frequently without relying on complex background build systems, which reduces integration problems.

Contraindications

Every project should have a good automated build. Even if you have a system that's difficult to build, you can start chipping away at the problem today.

Some projects are too large for the ten-minute rule to be effective. Before you assume that this is true for your project, take a close look at your build procedures. You can often reduce the build time much more than you realize.

Alternatives

If the project truly is too large to build in ten minutes, it's probably under development by multiple teams or sub-teams. Consider splitting the project into independent pieces that you can build and test separately.

If you can't build your system in less than ten minutes (yet), establish a maximum acceptable threshhold and stick to it. Drawing this line helps identify a point beyond which you will not allow more technical debt to accumulate. Like a sink full of dishes two hours before a dinner party, the time limit is a good impetus to do some cleaning.

• Next: Continuous Integration
• Previous: Version Control
• Up: Chapter 7: Releasing

Comments

30 Jul 2010 James Shore/Blog

This week's excerpt from The Art of Agile Development is Ten-Minute Build.

These days, my favorite build tool is Rake. I like to create multiple batch files or shell scripts for running Rake: dev, for building and testing on the local machine; repo, for manipulating the version control repository; and deploy, for shipping iteration and production releases. Each script gets its own Rake file, and then I take advantage of Rake's Ruby underpinnings to put code common to the various rakefiles in shared Ruby classes.

Next week's excerpt: something from the Planning chapter. Voting is back to normal this week, so please speak up for your choice in the comments. Here are your choices:

• Vision
• Release Planning
• Risk Management
• Stories

Comments

Please note: borisgloger.com became multilingual! The original feed now contains solely German content. To follow borisgloger.com in English please update your feed-subscription.

Ein guter Teamleader hält sein Team immer bei Laune, ist doch klar! Und dank der Scrumlies wissen wir jetzt auch, wie man die Sache richtig angeht! ;-)

Das war nun Woche Vier der Summer School, Halbzeit also. Nächste Woche behandeln wir das Thema “Scrum & Vertragswesen” das wir am Montag mit einem spannenden Leitartikel von Marcus Antonius Hofmann, Rechtsanwalt aus München, einleiten werden.

Ein schönes Wochenende, wir sehen uns nächste Woche!

The days of multi-hour delays at the airport aren't gone by a long shot, but things at JFK at least are considerably better than they were. The Wall Street Journal writes about the new software system the airport is using to reduce the lineup of planes on the tarmac.

In contrast to European airports, which assign specific takeoff times to each flight, the FAA has always allowed planes to depart first come, first served. Consequently, if flights didn't leave the gate and get in line on the taxiway, they didn't go. That's why you had to spend 90 minutes in seat 22K with the screaming children instead of the Admiral's Club.

Essentially, the airports were treating the departing planes as one giant batch. (At least that's interpretation, but I'm not an industrial engineer.) With the new software, however, they're working with small batch sizes:

Now, airlines file flight plans with the Federal Aviation Administration indicating what time they want to take off. A metering program compiles requests, and takeoffs are scheduled in 15-minute blocks of time. Airplanes don't leave the gate until their assigned time. And as a result, the conga line of 40 jets lined up at the end of a runway has been reduced to six to eight.

Okay, this doesn't really eliminate the delays -- it just shifts them from the tarmac to the airport terminal. But that's good for passengers, who really don't want to spend any more time than absolutely necessary in the plane, and it's good for the airline, who save money on fuel costs:

Airlines get a big bonus, too, in fuel and maintenance savings. Engines can burn lots of fuel idling and revving up to move forward in line. And engine maintenance is often scheduled and paid for by the hour, so taxiing for an extra hour each day can significantly run up maintenance costs.

And by having smaller batch sizes on the taxiway, logistics for the airlines and the airport are far easier:

when shifting winds force takeoffs and landings onto different runways. With fewer planes in line, it doesn't take as long to re-arrange the airport.

Managing the flow of traffic is still a staggeringly complex process. Even with this new software and system, airplane mechanical problems and sudden weather changes will wreak havoc. But it's nice to see how smaller batches can pay off in yet another arena.

Now, if they could only make a larger batch size for seat legroom.

I thought I’d take a quick moment to provide some examples of making object properties read only in EcmaScript 5 (and by extension node.js). There’s several ways to accomplish it, so I’ll just iterate over all the different ways.

Object.freeze

The quickest way to make all properties of an object read only is by calling Object.freeze on it. The interesting thing here is that (at least in node.js) no exception or warning will take place if you try to assign a read only property… it will appear that the assignment succeeded when in reality it didn’t.

Let’s try an object with some additional types… nested object and an array.

In this example, we see that the array and object represented by b can in fact be modified, they just can’t be reassigned to something new. It really just locks the reference. However if we loop over each property and freeze each one each will be unmodifiable and the attempt to push an element onto the array with throw an exception stating TypeError: Can't add property 4, object is not extensible.

Define Only a Getter

Another way to make a property read only is by only defining a getter for it. You can do this both via defineProperty or defineGetter

Both will throw an exception on an attempt to reassign them.

Defined as Not Writable Via Property Descriptor

One more way is to define the writable attribute in the property descriptor.

That’s just a quick overview, there’s also quite a few interesting tricks to locking object instances.

Michael Balle has a very interesting post on "making people before making products":
When I first studied how Toyota engineers implemented TPS at a supplier, they always knew what the next step was, and so I assumed (as did the supplier’s engineers) that had a roadmap of how they wanted to make the cell progress. I kept badgering them to show me this map, thinking that they didn’t want to share this for proprietary reasons. The Toyota guys always refused, explaining that they didn’t have a roadmap. All they were doing was focusing on problems as they appeared and then working hard at solving them. One day, exasperated with my annoying questions, the lead engineer said to me” “WE DON’T HAVE A ROADMAP. But—we do have kind of a golden rule: making people before making parts.” I’ve tried to puzzle this out ever since.He has a quote from a CEO that I like:
“I don’t want people who will do the job right. I can find those any time. I want people determined that the next time they’ll do the same job, they’ll do it better. Those are the people I need."

Today I invented a phrase (at least I think I invented it because I haven’t heard anyone else say it): “Avoidable Heroism.”

I invented it in response to a question, “Should my team work on the weekend to meet a commitment made under their control?”

Now, I don’t know the background behind this question. Maybe it’s perfectly reasonable for them to work on the weekend. Maybe they have no agreement about sustainable pace. And, it raises a few questions in my mind. How often does this happen? How far from the commitment are they? When was the first, best opportunity to re-negotiate the commitment? How did it slip by? What else is happening that affects their ability to commit and deliver?

Avoidable heroism happens on teams when the system pressures the team into committing to “stretch” iteration goals (rather than evidence-based goals) and someone (or more than one someone) has to work nights and weekends to meet the commitment.

Avoidable heroism occurs when unit test coverage goes down, team members focus on cranking out quantity of code rather than quality code and “forget” TDD, so that at a certain point a team member throws themselves on the technical debt grenade and begins to clear away the debris.

Avoidable heroism ensues when team members hand the new code to the testers on the last day of the iteration, rather than including them as part of the cross-functional teamwork from the first day.

And so on.

In the 1980’s (yes, I know that was before many of you were born), Tina Turner sang an anthem, “We don’t need another hero!”. Make it your own, your team anthem.

N.B.: I hope someone out there who’s into writing anti-patterns will collaborate with me on documenting this one.

I remember the first time I drove a car on a race track.  I was hooked, and to this day I am a motorsports fan and occassionally enjoy getting to autocross or driving on race tracks.
 
The basic knowledge of how to become a race car driver is not hard to learn from books and lecture.  I've been to several driving schools.  The hard part is applying all you learn to driving the car on the track with speed and smoothness.  The greatest improvements I've made in my driving have always come when I've had a coach in the car with me, either driving the car for me to observe or as a passenger providing feedback and instruction. There is a reason that professional race car drivers have undergone many hours of professional coaching long be fore they will ever be awarded a racing license.
 
Becoming a competitive race car driver is basically the same same learning model as becoming a doctor or a practitioner in an agile software development organization:

• Training and reading build knowledge
• Applying that knowledge so that the desired outcome can be repeatedly achieved is skill
• Repeated application of that skill in different circumstances forms experience

 This process, unfortunately, is lost on most sponsors who cause one of the biggest agile adoption anti-patterns: Coaching not necessary. This is the idea that one 2-day course or just reading some books will instantly create a set of agile practitioners. It takes time, dedication, experimentation, and most of all, coaching, from an experienced agile coach who is either in-house or external.

Would you trust a lifeguard who received her certification on the Internet based on an online exam and no practice? What about a surgeon who has never had any internships, residencies or hands-on experience? Would you trust him to operate on you? I understand that a newly trained agile developer isn’t going (usually) to kill anyone if they miss an iteration goal or their retrospective goes sour, but the concept is still the same – getting results from an agile transformation takes experienced practitioners. One cannot go directly from knowledge to experience, and one cannot build skills in the classroom. To achieve the desired results from agile teams, it takes time to nurture and grow them, and that includes coaching along the way.

Don’t get me wrong. I’m not out to say that agile practitioners aren’t bright and can’t apply what they have learned in the class or book within their own environment. But consider your unique environment – your corporate culture and the quirks that are yours alone, your current environment, infrastructure, leaders and their leadership style, organizational structure, incentives, and so on. There are so many parts to the makeup of an organization that sometimes it isn’t obvious how to apply what you have learned. A 2-day course (or even a 10-day course) cannot cover all possibilities. And what about scaling agile? The more teams there are (especially distributed teams), the more  challenges the newly trained agilists face. It gets overwhelming, especially for new practitioners.

In addition, please don’t misinterpret my views about classroom time. I have done my share of teaching. I love teaching and I will be the first to point out that classes and books are an essential start. They add the knowledge which is required to start the journey. However, it will never build skills. Application of new knowledge in your own environment will do that. And the more complex the environment, the harder it is to apply that knowledge. Coaching from someone who has done it before and seen many of the pitfalls the team may be headed for, who will work with them to navigate the rocky terrain, teaching them within their own context and arming them with the tools to apply that knowledge to make wise decisions. In essence, the coach’s job is to work themselves out of a job. Repeated application of that skill in different circumstances forms an experienced practitioner who, by the way, is your next agile coach.

Don’t try and save the cost of some coaching and try and get everyone trained instead, thinking this will bring about results. Instead, consider picking a smaller subset of the whole who can be trained AND coached in their own environments, who, because of the coaching, will come up to speed faster, avoid common mistakes and ultimately coach the next generation. Consider that what you may consider an expense may actually be an investment, which will pay dividends for years. 

Remember, nothing breeds acceptance of change in an agile transformation like success.  A well trained and coached agile core group with multiple successes is the best marketing for the effort and the best foundation fo scaling agile. 

I'd like to thank Darian Rashid of Agile Ethos, a VersionOne Partner, for collaborating on this post with me.

Does Amazon maybe have too many ways to provide feedback?

This would be easier to explain face to face and I could point at the screen.

Take a look at this: http://www.amazon.com/review/R39AXJMKKO2WE5/ref=cm_cr_pr_cmt?ie=UTF8&ASIN=1422110664&nodeID=#wasThisHelpful

It's a comment, on a customer review of the book The Power of Positive Deviance.  

I found the 1st comment (by Mobster 94) intriguing.  The commenter gave the review a "was not helpful" vote and then left a reason to explain why.  I've not seen that before.  The reason surprised me too - the commenter thought the review was too long even though it was well written.  Never seen that before.

So, here you've got 4 different types of feedback: 

1) A review

2) A vote on whether the review is useful

3) A comment explaining why the commenter thought the review wasn't useful.

4) A comment from the reviewer suggesting that the commenter reads other people's reviews instead

And now, a 5th and 6th, which came from me clicking Yes, then No, on (3) and (4) above to Amazon's question "Do you think this post adds to the discussion?"

I tried out the new dragon dictation iphone app last week and WOW it worked well, even with my kiwi accent.  The app is small and simple with  the grunt work on Dragon's servers.  I don't think I'll use the app but it is an impressive piece of work - and free.

But ... here's the really clever bit: according to David Pogue's latest NYTimes article, Dragon have been anonymously saving the iphone data on its servers and then using inside their development process to improve the software's accuracy. I like that: provide something free that is useful to non-customers so that you can improve your product for new customers. Nifty.

Several years back, I did an exercise in mapping out families of application architectures and application types.  It was an extensive archeological expedition.

Key Goals / Outcomes
There were several goals of the exercise:

• Identify canonical application architectures and app types
• Figure out a useful way of sharing architectures
• Figure out whether it's better to focus on the business architectures or the technical architectures
• Find a simple way to overlay patterns work on top of technical architectures
• Find a simple way to share architectural styles
• Find a way to simplify and share visuals of end-to-end architectures

The exercise fed into a number of later works years later, including:

• Re-shaping the patterns & practices catalog to be organized using app types -- and this literally drove our product-line more formally toward app types (a pre-cursor to the patterns & practices "factories" effort in 2005)
• Identifying a canonical set of application types for the Microsoft platform as part of the Application Architecture Guide.
• Shaping the path of the home/hub pages on MSDN toward "deployment targets" and application types

Key Activities
Some of the key activities of this early exercise included:

• Creating an exhaustive catalog of application types grouped and sliced in various ways
• Interviewing many of our best application architects in the trenches
• Sanity checking with many of our top architects at head quarters, including Rico Mariani, Pat Helland, and Jim Gray
• Reverse engineering many available sample applications inside and outside of Microsoft
• Checking with industry experts on their lessons learned about the types and the shapes of all the applications they've seen and built over the years
• Creating an extensive inventory of application patterns from various sets of our  key customers that had a wide range of applications and platforms
• Evaluating competitive efforts to index and catalog application shapes and types, and making sense of various patterns efforts

Keep in mind, that going into this, I already had the benefit of doing more than 650 customer architecture and design reviews -- yet still, this was an overwhelming exercise.  It forced me to find new ways to deal with large bodies of data and information, and somehow turn them into  shared maps, browsable, reusable knowledge nuggets, and backdrops for deeper conversations and elaboration.

Lessons Learned from Architectural Exploration
Some of the surprises for me or things that I learned that I didn't expect include:

• Focusing on business architectures and verticals was less effective and less reusable than focusing on technical architectures as a baseline (from there, we could overlay business architectures)
• Knowing the deployment patterns was the fastest way to get a good sense of the application patterns (it's where the logical met the physical against the infrastructure)
• Looking through quality attributes as a lens made it easy to find and explore patterns for security, performance, reliability, manageability, etc.
• So many applications boiled down to simple CRUD (Create Read Update and Delete)
• The biggest variation among applications was the business logic and workflow
• IBMs simple model of user, process, and data was useful as one lens
• Views and viewpoints were a powerful way to change perspective and drill into another aspect of applications
• At a high-level, you could capture a customer's core system by capturing the data, workflows, and workloads (the workloads significantly shaped the design of the app)

In retrospect, the simplicity and common denominators of CRUD make a lot of sense.  It's all about interacting with information at a fundamental level.  People are just trying to get things done and there's only so many things you can do with information -- find it, browse, save it, share it, transform it, etc. as part of your workflow.

Early Map of App Types
I included one of the many early maps of the application types that helped us figure out what to throw out and what to keep as we moved forward.   One of the key distinctions that Ward Cunningham helped me figure out was to distinguish between the shape of the application architecture and design, and the actual “purpose” of the application.  Some purposes were more business-oriented, while some were more technically oriented, and this helped me find and distinguish different families of apps.

It's circa 2004, but the irony is how timeless the backdrop really has been.  It’s rough and raw, but like I said, it’s just one sampling of the many braindumps behind the scenes of mapping out app types.

 

Category Items Base Archetypes

• Rich Client
• Web Client
• Web Service
• Mobile / Phone
• Video Game

• Framework
• Component/Library
• Subsystem
• Service

Pool of Stuff

• OLAP
• Data Mining
• Data Warehouses
• Data Management
• Business Process Integration
• Business Intelligence
• BAM

• Server-side
• Desktop
• Peer-to-peer
• Mobile
• Web-centric
• Data-centric
• Middle-tier

• Transactions
• Read-Only data
• Workflow
• Batch

• Portal
• Community
• Commerce
• Task-Tracking

Business Applications

• Accounting and Finance
• Customer Service
• Distribution and Warehousing
• Education and Training
• Engineering, Design and Drafting
• Facilities Management
• General Office Automation
• Groupware and Collaboration
• Human Resources
• Knowledge Management
• Legacy Systems Analysis and Upgrade
• Logistics and Procurement
• Manufacturing and Process Management
• Other Business Application Tools
• Project Management
• Reporting, Analysis and Decision Support
• Sales and Marketing

Accounting and Finance

• Account Activity Analysis
• Accounts Payable
• Accounts Receivable
• Billing and Invoicing
• Budgeting, Financial Planning and Analysis
• Consolidation Statements and Performance Reporting (CS-PR, Aggregation)
• Currency and Foreign Exchange Management
• Electronic Funds Transfer (EFT)
• Fixed Asset Management
• General Ledger
• Integrated Accounting Solutions
• Integrated Financial Management Solutions
• Inventory Accounting
• Investment and Portfolio Management
• Job Costing
• Payment, Clearing and Settlement Systems
• Payroll and Personnel Accounting
• Purchasing
• Quotation, Order Entry and Order Processing
• Risk Management
• Small Business Accounting
• Tax Preparation and Reporting
• Time and Billing

Customer Service

• Automatic Page-Voice Notification
• Call Center Management
• Customer Service
• Help Desk and Call Management
• Interactive Voice Response Systems
• On-line Customer Support
• Scheduling

Distribution and Warehousing

• Distribution and Warehousing (Integrated)
• Freight Dispatch
• Freight Handling
• Other Distribution and Warehousing Industry Sectors
• Route Scheduling
• Truck-Fleet Management
• Wholesale Distribution and Warehousing

Education and Training

• Computer-Based Training
• Courseware Development
• Web-Based Training

Engineering Design and Drafting

• Cartography-Mapping-Geographic Information Systems (GIS)
• Computer-Aided Design (CAD)
• Computer-Aided Manufacturing (CAM)
• Electronics Design Automation (EDA)
• Materials Analysis
• Mechanical Computer-Aided Design (MCAD)
• Mechanical Computer-Aided Engineering (MCAE)
• Mechanical Computer-Aided Manufacturing (MCAM)
• Modeling
• Sampling and Testing
• Structural Analysis

Facilities and Management

• Building Security
• Communications Management
• Computer Maintenance Management (CMMS)
• Energy Analysis and Management
• Enterprise Asset Management (EAM)
• Equipment Maintenance and Field Service
• Facilities Maintenance
• Facilities Management (Integrated)
• Heating, Ventilation and Air Conditioning (HVAC)
• Lighting Analysis and Control
• Other Facilities Management Industry Sectors

General Office Automation

• Appointment Management
• Calculators
• Calendaring & Scheduling
• Data Entry
• Desktop Management
• Desktop Publishing
• Electronic Mail
• Fax Management
• Flowcharting
• Graphics (Raster)
• Graphics (Vector)
• Mailing List Management
• Multimedia and Animation
• Office Suites (Integrated)
• Presentation Applications
• Spreadsheets
• Time Management
• Time and Expense Reporting
• Voice Recognition Software
• Web Browsers
• Word Processors

Groupware and Collaboration

• Chat and Discussion Systems
• Collaborative Writing Systems
• E-mail Clients
• Group Calendars
• Integrated Groupware Solutions
• Newsgroup Management
• Resource Scheduling
• Video Conferencing and IP-TV
• Workflow Automation

Human Resources

• Benefits Administration
• Employee Self-Service Software
• Human Resource Management
• Integrated Human Resources Utilities
• Personnel Administration
• Professional Services Administration
• Recruiting
• Resume Tracking
• Time & Attendance
• Travel Management

Knowledge Management

• Computer Output to Laser Disc (COLD)
• Document Imaging Systems
• Document Management Systems
• Idea Management
• Knowledge Base Management
• Workflow

Legacy Systems Analysis and Upgrade - Logistics and Procurement

• Import and Export Management
• Partnership Relationship Management
• Requisitioning and Procurement
• Supply Chain Management
• Transportation Management
• Warehouse Management Systems

Manufacturing and Process Management - Capacity Requirements Planning (CRP)

• Data Reduction
• Distribution Management
• Enterprise Resource Planning (ERP)
• Equipment Maintenance and Management
• Factory Automation and CIM
• Factory Data Collection
• Inventory Management
• Machine Tools
• Machine Vision
• Maintenance, Repair and Operating Supplies (MRO)
• Manufacturing Automation Protocol
• Manufacturing Execution Systems (MES)
• Manufacturing Simulation
• Manufacturing Solutions (Integrated)
• Material Requirements Planning (MRP)
• Materials Manufacturing
• Metrology
• Numerical Control (NC)
• Operations Planning
• Plant Maintenance and Service
• Process Control (HMI-SCADA)
• Product Information Management (PIM)
• Product Service
• Production Planning
• Production Scheduling
• Quality Control
• Reliability Modeling and Analysis
• Robotics
• Shop Floor Control
• Test Development
• Test Information Integration
• Test Simulation
• Work Load Control

Project Management

• Project Accounting
• Project Estimating
• Project Management (General)
• Project Scheduling
• Purchasing
• Resource Planning

Reporting, Analysis, and Decision Support

• Business Planning
• Business Process Reengineering
• Competitive Analysis
• Data Mining and OLAP
• Decision Support Systems
• End-User Query and Reporting
• Executive Information Systems
• Expert Systems
• Mapping and Visualization
• Multi-Dimensional Analysis
• Needs Analysis Systems
• Neural Networks
• Statistics and Technical Data Analysis
• Trend Analysis

Sales and Marketing

• Contact Management
• Customer Relationship Management
• Demographics
• Enterprise Marketing Automation
• Lead Distribution Management
• Market Research
• Marketing Management
• Media Planning and Buying
• Mobile Field Sales
• Partnership Management
• Product Configurators
• Sales Analysis & Reporting
• Sales Force Automation (SFA)
• Sales Management
• Telemarketing

Industries

• Aerospace & Defense
• Automotive
• Chemicals
• Communications
• Consumer Products
• Education & Research
• Energy
• Engineering & Construction
• Financial Services
• Healthcare
• High Technology
• Industrial Manufacturing
• Life Sciences
• Professional Services
• Public Sector
• Retail
• Travel & Transportation
• Utilities

Business

• Contact Management
• Customer Management
• Accounting

Data

• Datawarehouse
• Data mining
• OLAP

Desktop

• Photo Editing
• Graphic Design
• Web Publishing

Desktop Business Software

• Email Client
• Spreadsheet
• Presentations
• Word Processing

Home and Hobbies

• Cooking and Health
• Fashion
• Gardening and Landscape
• Genealogy
• Hobbies
• Home Design
• Home Publishing
• Instrument Instruction
• Legal
• Mapping
• Movies and Television
• Music Appreciation
• Personal Improvement
• Script and Screenwriting

Personal Finance

• Investment Tools
• Money Management
• Tax Preparation

Utilities

• Virus Protection
• PC Maintenance

A

• Batch
• BPM (business process management)
• BIM (business intelligence management)
• EAI (enterprise architecture integration)
• Document Management

B

• Operating System
• Framework
• Component/Library
• Service
• Subsystem

C

• Portal
• Community
• Commerce
• Task-Tracking

D

• Transactions
• Read-Only data
• Workflow
• Batch

E

• Server-side
• Desktop
• Peer-to-peer
• Mobile
• Web-centric
• Data-centric
• Middle-tier

F

• Content Management

G

• Web Server
• Application Server
• Database Server

H

• Collaboration Suite

I

• OLAP
• Data Mining
• Data Warehouses
• Data Management
• Business Process Integration
• Business Intelligence
• BAM

There appears to have been a data center outage early morning, affecting a number of applications including Pivotal Tracker. This has caused connectivity problems for users in some locations, and it appears to still be persisting for some.

We're working with our hosting provider to get this resolved as soon as possible, this is our top priority.

This is the second data center outage this week. At the moment, we do not have enough information to know whether the outages are related.

Also, we have received reports that Tracker has been unreachable from certain parts of the world (including China) since the migration to a new data center last week. We've filed a request with Engine Yard to investigate, and hope to have this resolved soon.

Our apologies for the inconvenience these outages have caused. We'll post more information here as we receive it. You can also follow @pivotaltracker on Twitter for updates.

Like many github users, I often create forks for projects whenever I want to pull down their code, rather than cloning from the source directly.  This is pretty much the default way of working on github, as the site encourages collaboration through individualized repositories.  On my github page, this is what you’d see for my repositories:

It’s front and center, right on my home page.  Only two of those repositories were ones that I created completely fresh, and the rest are forks.

The other day, I posted a question on the StructureMap mailing list, but wound up getting a response in a github pull request!

This is because it’s just as easy to fork a user’s repository as it is the central repository.  Even the concept of a “central repository” isn’t ingrained in git (or github), there are only “blessed” repositories that the OSS project’s organizers agree upon.  For example, the “blessed” AutoMapper repository is just the AutoMapper repository in my github.

Pretty sweet, I can pull in this request locally, as well as any upstream StructureMap changes (as Git allows me to have as many remotes as I want), and see if it works for me.  If it does, I can then issue a pull request to the blessed StructureMap repository.  But if it doesn’t go through, no worries, I have my own StructureMap repository :)

Comparison to CodePlex

CodePlex is fantastic for a public-facing project hub, but it’s still not close to github on the OSS collaboration side.  Here’s an example, my homepage for the AutoMapper repository looks like this:

I have a wealth of information at my disposal here.  For new users, it’s a one-click operation to watch the project, fork it, create a pull request.  I can see how many folks follow the project or forked it.  All the information here is about the repository itself, rather than a project.  Github has a separate page for that, but by default, it’s about collaboration rather than documentation.

On CodePlex, I get a list of checkins:

The list of forks isn’t that much better.  CodePlex is definitely making strides, but you can definitely tell the difference between an OSS project hosting site built around DVCS versus one around centralized version control.  In github, its design is built around distributed collaboration, centered around individual commiters.  In CodePlex, its design is built around centralized projects.

Both definitely have their benefits, as it’s super-easy to get a URL to the CodePlex AutoMapper project page:  http://automapper.codeplex.com.  In fact, I kept the project on CodePlex because its support for project-centric activities I felt was better.  However, its support for collaboration-centric workflows still is pretty far away from github.  Unfortunately, CodePlex has to support both centralized (TFS) and distributed (Hg) source control systems, so I’m not sure how it’ll all shake out in the end…