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.

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.

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

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…

Golly, I've not written anything here in a month or so. Time for an update:

• After losing the mighty Mary Nolan to antipodean climes (if you are in Australia: hire her FAST), we're looking for a new Product Owner. The quality of candidates we've had so far has pleased us mightily, we're interviewing at the moment and it's going to be a tough decision.
• Did I forget to mention that we hired a new ScrumMaster a few months ago? After an 8-year break, Cori Samuel (FP Employee #1 back in 2001) has returned to the fold and taken charge of keeping our teams and process singing: two wheels of our cart.
• Two of our products are doing quite nicely, thankyou. Roulette Cricket has been featured in the "What's Hot" list by Apple for a little while now and has passed 80,000 downloads; the app is also now brought to you through sponsorship from BlueSquare, the gambling site. Meanwhile the Guardian Anywhere has now had more than 16,000 downloads with a retained audience of over 6,300 - and we've distributed more than 300,000 copies of the Guardian to this audience, with more than 50,000 in the last 3 weeks.
• We're heads down on a a couple of really interesting projects: new operating systems, new hardware, new design metaphors, exposing genuinely useful services to a new audience, and a pleasing physical/digital mix. I should be able to talk about one of these quite soon, and I'm looking forward to showing them off - they're looking gorgeous.
• I'm spending a bit more time than usual in London, helping some new friends lovingly kick in some doors (mainly advertising agency doors). Our Proposal Engine is humming nicely.
• Magazines and publishing are occupying a lot of neurons right now. With respect to m'learned friends at BERG (whose Popular Science is a thing of great beauty and gets lots of stuff right), I don't think that anyone has quite cracked this yet, and I'm hoping we get a chance to play here.
• Future Platforms will be 10 years old next month. This is both wonderful and terrifying, I'm hoping we can find an appropriate way to celebrate this.

Also - some interesting stuff I've been meaning to link to:

• I thought the Old Spice campaign was fantastic - the sheer frivolity tickled me, of coruse, but the live element of it also pessed a few buttons. For me it's another data point on a line we've plotted between Ghosty and Roulette Cricket. I'm looking forward to seeing the first mobile-first campaign like this. I'm hoping we get to do that one.
• The era of online anonymity as default may be coming to an end: "Standing behind your words, owning them and the consequences they have on others, is part of adult communication. And it’s time that communication on the Internet grew up a little."
• Fake, a tool for test automation on the Mac.
• How we built teleport, an intelligent counterpoint to the "price-em-low, shift units" mentality which dominates app sales today. It seems common-sense that there will be successes with many different pricing strategies.
• What an iAd looks like. I'm really curious to see whether the response rates from iAds will justify the much higher production costs, or whether Apple are going to carve out and own "brand" advertising and leave response to Google.
• Zero tolerance for latency: "For classical medias, we are just seeing the beginning of a vast catching-up phase. In doing so, the incumbents face digital native challengers that are way more skilled than they are in dealing with interfaces and with zero latency delivery."

This months favourite new blog? The Ad Contrarian. Favourite new Tweeter? The sadly-quiet Brignumeeja, who seemed to fall over just as they were getting started. A shame, some of the scene here would benefit from a bit of a dressing-down and taking itself less seriously.

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.

Unser Kunde, ein bekanntes und erfolgreiches WEB 2.0-Unternehmen, sucht am Standort in Berlin einen Product Owner (m/w).

Verantwortung: Du bist für die Entwicklung eines Teilbereichs verantwortlich. Dabei nutzt Du Markt- und Nutzeranalysen, um tragfähige Produktkonzepte zu entwickeln und bisherige Funktionalitäten auf Basis interner Analysen kontinuierlich zu verbessern.

Du übernimmst die inhaltliche Führung eines dedizierten Entwicklungsteams, mit dem Du, der Scrum-Methodik folgend, neue Funktionalitäten für die Plattformen umsetzt. Du bist Ansprechpartner für externe Entwicklungspartner sowie interne Kunden aus den Bereichen Marketing, Sales und Software Development.

Du solltest sehr gutes technisches Fachwissen mitbringen und ganzheitlich am Social Media Phänomen interessiert sein.

Deine Kompetenzen und Erfahrungen:

• Abgeschlossenes Studium im wirtschaftlichen oder technischen Bereich
• Mind. 4 Jahre Erfahrung im Internet Product Management oder in einer Agentur ausgeprägtes technisches Verständnis, insbesondere zu Frontend-Themen
• Tiefes Verständnis von Business Modellen im Internet
• Sehr gute Kenntnisse gängiger Analyse-Tools und damit einhergehend ausgeprägte analytische hervorragende Kommunikationsfähigkeiten und diplomatisches Geschick
• Hohe Durchsetzungsfähigkeit sowie hohe Belastbarkeit Scrum-Erfahrung von absoluter Vorteil

Bei Interesse bitte melde dich bei André Häusling von www.scrumjobs.com: andre.haeusling@scrumjobs.com

Dieses Posting ist eine Anzeige.

Next SoCal #Kanban / #Lean Software #meetup on 8/24 @ CityGridMedia: Lean Ancestry & Lean Games http://bit.ly/a9qH7B

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.

Was macht eigentlich ein “gutes” d.h. effektives Team, z.B. ein Scrum-Team aus? Sicher sind es viele Faktoren, die vorhanden sein und zusammenspielen müssen. Ein wesentliches und erwünschtes Element “guter” Teams ist sicher das, was man allgemein als Teamgeist (manchmal auch Wir-Gefühl) bezeichnet. Teamgeist wird immer wieder regelrecht beschworen, und es wird an die Teams appelliert, doch (mehr) Teamgeist (im Sinne einer eher moralischen Kategorie) zu zeigen.

Jedoch, Teams haben keinen Geist, schon gar nicht in der Initialphase. Sie entwickeln, gestalten und pflegen ihn ganz handfest als permanenten Prozess und, wenn vorhanden, als positiv erlebtes, emotionales Phänomen. Teamgeist ist zum einen ein interner Zustand, der aus fundierter Kollegialität souveräner Individuen ent- und besteht.

Zentrale Basis für diesen erwünschten Prozess ist ein erfahrbares Wachsen von Wertschätzung, Respekt, Vertrauen, Zuverlässigkeit, Disziplin, Sicherheit und Aufeinander bezogen sein. Diese Teamgeist-Basis entwickelt sich durch gemeinsames Handeln, durch das gemeinsame Erbringen von Leistungen und konkreten Ergebnissen und zum zweiten durch dauerhafte kollektive und individuelle Erfolge und Erfolgsfeedback. Aber Achtung: oft wird dabei der individuelle Erfolg zu Gunsten des Teamerfolges geringer geschätzt oder bewertet.

Die Anerkennung individueller Leistungen und Erfolge im Rahmen der Teamleistung (durch die übrigen Teamkollegen) stärkt die individuelle Souveränität und damit die Komponenten Wertschätzung, Vertrauen ineinander und gegenseitiger Respekt. Im gemeinsamen Tun und Erfolgserleben realisieren sich Zugehörigkeitsgefühl, Zusammengehörigkeitsgefühl, Solidarität, Loyalität, Akzeptanz von Heterogenität, Dialogprozesse und Bereitschaft zu offener Auseinandersetzung und es gestalten sich Teamidentität und Teamgeist.

Teamgeist stabilisiert sich des Weiteren durch Zuschreibungen aus dem Team-Kontext.  Wenn einem Team direkt oder indirekt zurückgemeldet wird, dass es als spezifisches Team x/y wahrgenommen und erlebt wird, entsteht Identitätsfeedback. Dieses führt zur Klärung des Selbstbildes und zu einer für den Teamgeist zwingend notwendigen Grenzziehung nach außen. Laterale Teamführung, d.h. Teamführung ohne direkte disziplinarische Macht, sozusagen ”Führung von der Seite her”, unterstützt gezielt die beschriebenen Variablen zur Entwicklung von Teamgeist (z.b. im Daily Scrums, Retrospektiven, Impedimentprozessen, in der Kommunikation von Erfolgen nach außen, usw.) Sie macht Stolpersteine und Blockierungen für Teamgeist-Entwicklung (wie mangelnder Kontakt, zu wenig oder unangemessene  Kommunikation, nicht geklärte Konflikte, Egoismen, zu wenig Anerkennung, blindem Kollektivismus, etc.) transparent und unterstützt Teams dabei, sie gezielt zu bearbeiten.

"There are two ways to extend a business. Take inventory of what you're good at and extend out from your skills. Or determine what your customers need and work backward, even if it requires learning new skills." Jeff Bezos

Luiza Pagliari and I, Paulo Caroli, gave a talk on the history of Continuous Integration (CI) and CruiseControl at the 2010 FISL conference (International Free Software Forum).

We talked to Martin Fowler and other colleagues at Thoughtworks and to gather (and validate) data on CI and CruiSeControl history. Below is short presentation with this data.

Continuous Integration and CruiseControl history


Please contact me if you are interested in the CI history topic and blog about it. I will add your links to this blog post.