Category Archives: Software Development

Jason Fried: Why work doesn’t happen at work

In this TED talk, Jason Fried, founder of 37 signals, discusses how people get work done. When asked where do you go when you really need to get something done, almost no-one says: the office (unless it is early in the morning or late at night)? This is especially for creative people and knowledge workers. They need long stretches of uninterrupted time to concentrate. “The real problems in the office are the managers and the meetings.”

The main theme is that interruptions can severely damage performance, especially for what Peter Drucker called knowledge workers.

He offers 3 suggestions to make the office a place people can get work done. No talk Thursdays. And if that is too much how starting with 1/2 a day Thursday once a month. Second, replace active distraction (meeting, going and talking to a person) with passive distraction (email and IM) that a person can turn off when they need to focus. I have found this very useful myself. And third, cancel meetings. He closes with: I hope I have given managers reasons “to think about about laying off a little bit and giving people some time to get work done.”

Related: Understanding How to Manage GeeksBetter MeetingsWorkers Allowed Recreational Use of the Internet are More ProductiveManagement By IT Crowd Bosses

No True Lean Thinking or Agile Software Development

“There is no true value of any characteristic, state, or condition that is defined in terms of measurement or observation.” – Dr. W. Edwards Deming.

The value depends on your operational definition.

Once you operationalize management ideas in a real organization it necessarily should have differences from how it is operationalized elsewhere. As Deming said there are no effective simple recipes for management. It is one of the frustrations people have with Dr. Deming: that there is no cookbook telling you what you should go do as a manager. You need to understand things like: interactions, variation, psychology, systems thinking, how we know what we know (and what we “know” that isn’t so). And then you need to make decisions about how to apply these concepts in your organization.

There is value in being able to think and discuss ideas in a broader context than your organization. You lose a great deal of learning opportunities if you can’t. And having common idea about what common principles a lean thinking organization or agile software organization should have is helpful I believe. That is aided by abstract ideals of these management practices.

Dilbert comic on the futility of process and arbitrary deadlines

One of agile’s guiding principles is individuals and interactions over processes and tools. I am a Deming follower and that emphasizes the importance of process and system. The words in agile are anti-process. But in my experience it is really a specific type of process – and that is basically idiotic adherence to process that the software developers are sick of. This attitude is best summed up in Dilbert. There are plenty of what I would call process in the practice of agile – sprints, kanban, work in process limits, define what done means, using user stories, retrospectives, build in quality… Basically I think it is important to understand what the principles mean, but don’t get locked into dogmatic ideas.

There are principles that seem to me necessary to, for example, consider an effort as lean management. There must be respect for people in lean management. If it isn’t there, then I don’t think it is lean. It might be management using some ideas and tools from lean, but it isn’t lean management. Exactly how respect for people is manifest is up to the organization. The same thing holds for other principles.

Thoughts on No True Agile, No True Lean, No True Latte

Related: Dr. Deming: There is No True ValueHow to Manage What You Can’t MeasureInvolve IT Staff in Business Process ImprovementThe Illusion of Knowledge

Continue reading

The role of leadership in software development

The webcast of Mary Poppendieck’s talk, The role of leadership in software development, at Google. As usual Mary does a very nice job of providing some good historical background while exploring wise management practices (tied to software development but plenty useful for any manager).

via: Sheep of a different fold

Related: Lean, Toyota and Deming for Software DevelopmentWebcast on the Toyota Development ProcessDon’t Use Performance AppraisalsLean Software DevelopmentThe Leader’s Handbook

Stop Starting and Start Finishing – Jason Yip

Jason Yip explores the value of reducing work in process and reducing context switching costs to optimize throughput. By designing processes to work on projects serially instead of in parallel we reduce context switching, and other costs, of multitasking.

Related: Multi-Tasking: Why Projects Take so LongThe Importance of Making Problems VisibleOne piece flow (continuous flow)Kanban

Involve IT Staff in Business Process Improvement

I started out basically working on management improvement from the start of my career. My makeup (I am never satisfied and figure things should always be better) along with a few traits, experiences and probably even genes made this a natural fit for me. I tend to take the long view and find fire fighting a waste of time. Why fix some symptom, I want to fix the system so that problem doesn’t happen again. My father worked in statistics, engineering and business improvement and as I was growing up I had plenty of experience with process improvement, understanding variation, experimenting, measuring results

I came into the IT world as I had needs and found the best solution was to write some software to help me accomplish what I wanted to. One thing that better software tools allowed is this type of thing when organizations failed to use technology well, individuals could just do so themselves. Without these tools people had to rely on the organization, but today atrophied IT organizations can often be circumvented. Though the IT organizations often try to avoid this largely by bans (instead of by providing the tools people need), which is not a good sign, in my opinion.

I then spent more and more of my time working with technology but I always retained my focus on improving the management of the organization, with technology playing a supporting role in that effort. That is true even as where I sat changed. And I have become more convinced organizations would be served well by using the information technology staff as business process experts.

At one point I sat in the Office of Secretary of Defense, Quality Management Office where I was able to focus on management improvement and using technology to aid that effort. Then I went to the White House Military Office, Customer Support and Organizational Development office and focused largely on how to using technology to meet the mission. Then I was moved into the White House Military Office, Office of Information Technology Management.

And now I work for the American Society for Engineering Education in the Information Technology department. My role started as partially program management and partially software development and as we have grown and hired more software developers I am now nearly completely a program manager.

I believe technology is a central component of understanding business processes today. But the truth is, many business people don’t have as complete an understanding as I feel they should. Now I believe, most anyone interested in planning their management career needs to develop a facility with technology and specifically how to use software applications to improve performance. You don’t need to be an expert programmer but you need to understand the strengths, weakness, limits of technical solutions. You need to understand how technology can be used (and the risks of options).

At the same time I just don’t think it is likely management everywhere will get a decent understanding of application software development. I also believe that in many cases organizations should do software development in house. This is a issue that certainly can be argued (but I won’t do it here). Basically I don’t think organizations should cram their processes into designs required by off the shelf software. Instead I believe they should design processes optimal for their organization and using off the shelf software often does the opposite (forces the process decisions around what software someone decided to buy). There is plenty of use for off the shelf software that doesn’t force you to make your processes fit into them (and sometimes even if it does that is the business decision that has to be made – I just think far too often organizations look at short term costs and not the overall best solutions for the system).
Continue reading

Trust Your Staff to Make Decisions

The failure to give your organization the flexibility to serve customers is a big mistake. Many companies make this mistake. Often the basic problem is managers don’t trust that their systems to hire and develop people that will make good decisions. The solution to this problem is not to give your staff no authority. The solution is to manage your systems so that you can trust your people. This is not as easy to do as it is to say, I will grant that.

Southwest Airlines and Zappos are companies that do respect employees. And those employees then provide great service. But it isn’t a simple thing. To truly manage a system with respect for people isn’t as easy as just putting up some slogans. But if you want to provide good customer service this is one requirement. There are plenty of others: continual improvement, evidence based management, customer focus, systems thinking

These thoughts were prompted by a nice post, jetBlue Just Blew It

You see, when I booked my flight last night I used their online system (good) and made a mistake in booking the date for my return (bad). I’m going to Boston for the weekend and accidently booked by return flight a month later in August instead of the 4 days I was looking for.

Of course their site has a lot of bookings and almost no one makes an error like this. But any UI designer who looks at their site could see that it’s absolutly possible since the length of the trip is never revealed except for the flight dates. (I”m arguing that they could put in a little fading header that tells you how long your trip is for.) If’ I’d see anywhere that my trip was scheduled for 35 days I’d have immediately know there was an issue. (I could make a simple change to the jetBlue UI that would solve this problem for everyone within a day.)

Today when I looked at my emailed itinerary I immediately spotted the problem and went online to change my ticket. They have a $100 change fee which I paid thinking I’d give them a call and that surely they’d waive that. After all, it wasn’t a change I was asking for, it was the ticket I wanted in the first place. It was less than 24 hours and the flight wasn’t for a month.

But no.

In speaking to the customer service rep who ‘called’ a manager. I was informed that I had only a 4 hour window to make any changes and that after that, there was nothing anyone could do. You see, no one at jetBlue customer service has the ‘authority’ to refuse this fee. It was company policy that they couldn’t actually do anything.

Continue reading

Mistake Proofing Deployment of Software Code

This is a continuation of my previous post: Improving Software Development with Automated Tests. Lets look at a typical poka-yoke example. A USB connector must be put in the right way up – for the connection to work properly and the communication to occur as intended. So to mistake proof the process the connector won’t allow the USB device to be put in upside down – the hardware connection designed to not allow that type of connection.

Using a deployment process that prevents code from being submitted that has an error follows a nearly identical process. The process blocks an error from being made. It seems to me a process that blocks code with a bug from being deployed with an error is the basically the same as a USB connection that will not accept the device being put in upside down.

Mistake proofing in no way should limit focusing on improving the process. Mistake-proofing a process both improves it (many poka-yoke solutions make the process easier to use) and prevents an error in case you still try something wrong. So I see the automated tests as a way to serve as a backstop, in case the process improvement you made to the software development process failed in some form. Then the automated testing required to deploy would prevent the introduction of that error to the production environment.

Related: Checklists in Software DevelopmentBaking in Quality to Software DevelopmentCombinatorial Testing for Software DevelopmentGreat Visual Instruction Example

Combinatorial Testing – The Quadrant of Massive Efficiency Gains

My brother, Justin Hunter, gives a lightning talk on Combinatorial Testing – The Quadrant of Doom and The Quadrant of Massive Efficiency Gains in the video above. The following text is largely directly quoted from the talk – with a bit of editing by me.

When you have a situation that has many many many possible parameters and each time only a few possible choices (a few items you are trying to vary and test – in his example in the video, 2 choices) you wind up with a ridicules number of possible tests. But you can cover all the possibilities in just 30 tests if your coverage target is all possible pairs. When you have situations like that you will see dramatic efficiency gains. What we have found in real world tests is greatly reduced time to create the tests and consistently 2 to 3 times as many defects found compared to the standard methods used for software testing.

You can read more on these ideas on his blog, where he explores software testing and combinatorial testing. The web base software testing application my brother created and shows in the demo is Hexawise. It is free to try out. I recommend it, though I am biased.

Related: Combinatorial Testing for SoftwareVideo Highlight Reel of Hexawise – a pairwise testing tool and combinatorial testing toolYouTube Uses Multivariate Experiment To Improve Sign-ups 15%What Else Can Software Development and Testing Learn from Manufacturing? Don’t Forget Design of Experiments (DoE)Maximize Test Coverage Efficiency And Minimize the Number of Tests Needed

Justin posted the presentation slides online at for anyone who is interested in seeing more details about the test plan he reviewed that had 1,746,756,896,558,880,852,541,440 possible tests. The slides are well worth reading.
Continue reading

Interruptions Can Severely Damage Performance

Interruptions can severely degrade your performance. The type of work you are doing impacts the cost greatly. I have spent some of my time programming web applications. When I am doing that interruptions are huge drain on my performance (for me the costs of interruptions while programming are far higher than any other type of work I have done – many times higher). If the interruption disrupts my flow (an interruption needn’t necessarily disrupt it I found, instant messages may not, while speaking to someone else almost surely would – it is a factor of how much of your brain much shift focus I imagine) it can take a huge amount of time to get back into a high performing state. Other work I do can be interrupted with much less impact. I am easily able to slip back into what I was doing.

For me the main cost of interruptions is the time it takes to get back to where I was before the interruption. And the cost is related to how much focus is needed to address what you are working on. Most programming takes a huge amount of focus.

Another big cost of interruptions is the increased risk of mistakes. When people are distracted and then have to go back to a task, and then are distracted, and then go back and… it is more likely they will miss a step or miss noticing some issue than if they can work without distraction. One tool to help cope for distractions that can’t be designed out are checklists.

Paul Graham addressed the importance of managing the system to provide uninterrupted time very well in, Maker’s Schedule, Manager’s Schedule

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

Paul Graham’s article also shows why managers so often fail to adequately address this issue. Manager, by and large, work in an environment where interruptions are the work. I know, much of my time as a program manager is driven by interruptions and is doable even with many interruption every day.

When managing you need to understand how big a cost interruptions have and design systems appropriate to optimize system performance for all parts of the system. The design of the system needs to take into account the costs and benefits of interruptions for those people working on various processes in the system.

Related: Understanding How to Manage GeeksExplaining Managers to ProgrammersWhat Motivates Programmers?Joy in Work – Software DevelopmentProgrammers CartoonChecklists in Software Development

Toyota’s Journey to Lean Software Development

Toyota’s journey from Waterfall to Lean software development by Henrik Kniberg

Toyota builds cars (duh). In the past that didn’t involve much software, and the little software that was needed was mostly developed by suppliers and embedded in isolated components. Toyota assembled them and didn’t much care about the software inside. But “The importance of automatic electronic control system has been increasing dramatically year by year” said Ishii-san.

A modern car is pretty much a computer on wheels! In a hybrid car about half of the development cost is software, it contains millions of lines of code as all the different subsystems have to integrate with each other. He mentioned that a Lexus contains 14 million lines of code, comparable to banking and airplane software systems. Ishi-san concluded that “Therefore Toyota needs to become an IT company”.

Most of Toyota’s ideas about how to do Lean software development resonated well with me. My feeling was that they are on the right track.

One thing bothered me though – the extreme focus on detailed metrics. I agree with the value of visualization, standardization, and data-driven process improvement – but only if used at a high level. My feeling was that Toyota was going to far. They say engineer motivation is critical, but how motivating is it to work in an organization that plans and measures everything you do – every line of code, every hour, every defect, how many minutes it takes to do an estimate, etc?

via: Justin Hunter

Related: Toyota IT OverviewToyota Canada CIO on Genchi Genbutsu and KaizenLean Software DevelopmentMy First Trip to Japan by Peter ScholtesToyota IT for Kaizen

Improving Software Development with Automated Tests

Automated software testing is a mistake proofing (poka-yoke) solution for software development.

The way automated testing works is that software code is written that tests the software code of the application. This automated testing code test that business rules are correctly being followed by the code in the application.

So for example, a user should not be able to create a new account without entering password. Then you create code that does not allow an account to be created without a password. And you write a test that passes if this is true and fails if it is false.

The best implementation will then not allow deploying code to your production environment until the code has passed all the automated tests. So if a software developer changes the code, the automated tests are all run and if there is an error noted by the automated testing the code cannot be deployed to the production environment. So, in the example above, if somehow the changes made to the application code somehow now let an account be created without a password the test would fail, and the developer would know to fix the problem before putting the code into production.

Thus automated testing mistake proofs the process. Now the mistake proofing is only as good as the test that are added. Software development is complex and if the code has an error (based on the business rules) that is not tested then the code can be deployed to production and affect customers. Automated software testing tools are a huge help in preventing many errors from affecting customers.

It seems pretty obvious but until the widespread adoption of agile software development techniques and frameworks that make it easy to adopt automated testing (like Ruby on Rails) this sensible process improvement tool was used far less often than you would think.

Related: Combinatorial Testing for SoftwareMetrics and Software DevelopmentChecklists in Software DevelopmentGoogle testing blogHexawise software testing blog

Observations of a New Googler

Some interesting thoughts from a new Google engineer, Things I’ve learned at Google so far

I would describe Google’s culture as “creative chaos”. There was some confusion about where I was supposed to be when I started. This resulted in the following phone call, “Hello?”, “Hello Ben, this is Conner (that’s my new manager), where are you?” “Mountain View.” “Why are you there?” “Because this is where the recruiter said to go.” “Good answer! Nice of them to tell me. Enjoy your week!” This caused me to ask an experienced Googler, “Is it always this chaotic?” The response I got was, “Yes! Isn’t it wonderful?” That response sums up a lot about Google’s culture. If you’re unable to enjoy that kind of environment, then Google isn’t the place for you.

Paul Buchheit was a software engineer at Google. He didn’t need permission to write something like gmail. Corporate culture says that if you need something like that, you just go ahead and do it. In fact this is enshrined as an official corporate policy – engineers get 20% of their time to do with pretty much as they please, and are judged in part on how they use that time. I found a speech claiming that over half of Google’s applications started as a 20% project. (I’m surprised that the figure is so low.) To get a sense of how much stuff people just do, visit Google Labs. No corporate decision. No central planning.

Sick day policy. Don’t show up when you’re sick and tell people why you’re not showing up. Note what’s missing. There is no limit to how much sick time you get if you need it.

I think he overestimates the lack of central planning, still it is another interesting view of Google.

Related: Eric Schmidt on Management at GoogleGoogle: Ten Golden RulesThe Myth of the Genius Programmer

Statistical Learning as the Ultimate Agile Development Tool by Peter Norvig

Interesting lecture on Statistical Learning as the Ultimate Agile Development Tool by Peter Norvig. The webcast is likely to be of interest to a fairly small segment of readers of this blog. But for geeks it may be interesting. He looks at the advantages of machine learning versus hand programming every case (for example spelling correction).

Google translate does a very good job (for computer based translation) based on machine learning. You can translate any of the pages on this blog into over 30 languages using Google translate (using the widget in the right column).

Via: @seanstickle

Related: Mistakes in Experimental Design and InterpretationDoes the Data Deluge Make the Scientific Method Obsolete?Website DataAn Introduction to Deming’s Management Ideas by Peter Scholtes (webcast)

Managing to Test Result Instead of Customer Value

Computer hardware and software creators use benchmarks as one tool to compare the performance of alternative products. At times this can be very useful. You can learn what software of hardware is faster and that may be a very valuable factor. However, any measure is determined by the operational definitions used in collecting the measure. And if people have incentives to improve the measured number they often will do just that (improving the measure) rather than improving the system (the measure is meant to serve as a proxy for some function of that system).

Information technology people actually understand this much better than most mangers (who also rely on measures for many things like return on equity, profit growth, productivity of various plants…) – so actually I find they are not nearly as fooled by measures compared to managers. On Reddit there is an interesting discussion on coding the product to provide good benchmark results [in this context benchmarking has to do with measured results on standard performance tests – not TQM style benchmarking). The technical details in this case don’t matter so much to my point, which is just that when people treat the measure as the true value instead of a proxy for the true value it is risky.

Technology companies compete fiercely and claiming the software or hardware is faster is one big area of competition. And the comment on Reddit is claiming one competitor changed some code only to get a better measure (that provides no benefit to customers). The problem with such actions, is they provide no actual value: all they do is make the measure less meaningful as a proxy.

Now it is also perfectly understandable why it would be done – when you are focused on improving the number, it might well be easier to distort the system to provide a better number (used by to measure performance) instead of actual improve the performance. It is easy to see why a company would do this if they want to have marketing claim their products are the fastest.
Continue reading

Understanding How to Manage Geeks

The unspoken truth about managing geeks by Jeff Ello

IT pros are sensitive to logic — that’s what you pay them for. When things don’t add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event. The more things that occur that make no sense, the more cynical IT pros will become… Presuming this is a trait that must be disciplined out of them is a huge management mistake. IT pros complain primarily about logic, and primarily to people they respect. If you are dismissive of complaints, fail to recognize an illogical event or behave in deceptive ways, IT pros will likely stop complaining to you. You might mistake this as a behavioral improvement, when it’s actually a show of disrespect. It means you are no longer worth talking to, which leads to insubordination.

Good IT pros are not anti-bureaucracy, as many observers think. They are anti-stupidity. The difference is both subjective and subtle.

The primary task of any IT group is to teach people how to work. That’s may sound authoritarian, but it’s not. IT’s job at the most fundamental level is to build, maintain and improve frameworks within which to accomplish tasks.

it’s all about respect. If you can identify and cultivate those individuals and processes that earn genuine respect from IT pros, you’ll have a great IT team. Taking an honest interest in helping your IT group help you is probably the smartest business move an organization can make. It also makes for happy, completely non-geek-like geeks.

The article makes very good points. As I have said before software developers expect more of management than most staff do. And I would say software developers are seen as more cynical than most staff because they accurately evaluate management’s failures (and are more willing to speak up about problems).

Pretending software bugs don’t exist doesn’t work. Pretending management bugs don’t exist doesn’t work either, but most are willing to pretend management bugs don’t exit. Programmers often figure bugs should be acknowledged and dealt with, rather than pretending they don’t exist. But they are called cynical when they mention management bugs – which only makes them less confident in the ability of management to preform their responsibilities.
Continue reading

YouTube Uses Multivariate Experiment To Improve Sign-ups 15%

Google does a great job of using statistical and engineering principles to improve. It is amazing how slow we are to adopt new ideas but because we are it provides big advantages to companies like Google that use concepts like design of experiments, experimenting quickly and often… while others don’t. Look Inside a 1,024 Recipe Multivariate Experiment

A few weeks ago, we ran one of the largest multivariate experiments ever: a 1,024 recipe experiment on 100% of our US-English homepage. Utilizing Google Website Optimizer, we made small changes to three sections on our homepage (see below), with the goal of increasing the number of people who signed up for an account. The results were impressive: the new page performed 15.7% better than the original, resulting in thousands more sign-ups and personalized views to the homepage every day.

While we could have hypothesized which elements result in greater conversions (for example, the color red is more eye-catching), multivariate testing reveals and proves the combinatorial impact of different configurations. Running tests like this also help guide our design process: instead of relying on our own ideas and intuition, you have a big part in steering us in the right direction. In fact, we plan on incorporating many of these elements in future evolutions of our homepage.

via: @hexawiseMy brother has created a software application to provide much better test coverage with far fewer tests using the same factorial designed experiments ideas my father worked with decades ago (and yet still far to few people use).

Related: Combinatorial Testing for SoftwareStatistics for ExperimentersGoogle’s Website Optimizer allows for multivariate testing of your website.Using Design of Experiments

Baking in Quality to Software Development

One of the reasons my organizations switched to Ruby on Rails for software development was the great integration with automated testing. We always wanted to have good test coverage on our software applications (which are web applications – some used only inside our organization) but didn’t actually find the time to do so. Since we adopted Ruby we have been doing much better in this regard. It isn’t just the switch to Ruby, of course, but the switch to Ruby coincided with the beginning of many improvements to our software development practices that have continually improved over the last couple of years.

Here is a post on How to build quality software by an agile, Ruby, lean software developer

I’ve mentioned previously about baking-in quality and not having developers throw code over a wall to testers.

Everyone on the team is concerned with not only assuring quality in what we deliver, but making it visible to ourselves and the business.

We work in an agile manner, iterating through development with extreme programming practices and Behaviour Driven Development. Facilitating our relationship with the business is Scrum and we utilise kanban principles and systems thinking to maintain a speedy throughput of high-quality work. This mixture allows us to communicate effectively, develop the correct features properly and continuously deploy our work when it is complete, thus maximising business value. I should also mention that we are fortunate enough to have our business people/customer sat across from us.

Without testers or a QA team there is no wall over which work can be thrown and the responsibility for quality absolved.

The inspection typically carried out end-of-cycle only yields bugs that were low severity and of no real impact to the end user.

An agile testing must-have, we use TeamCity to continuously run our unit tests on each check-in. We also execute our Cucumber acceptance tests on scheduled runs. The status of the builds are visible on dedicated monitors around the office as well as a nice 6′ projected screen.

via: @benjaminm

Related: Combinatorial Testing for SoftwareChecklists in Software DevelopmentSoftware Supporting Processes Not the Other Way AroundSoftware Development and Business Process SupportTop Blogs for Software DevelopmentHexawise: more coverage, fewer tests (my brother’s company)

Three Years of Real-World IT Projects In Ruby

Nice webcast by Martin Fowler, Three Years of Real-World Ruby. This talk is probably only of interest to those of you in software development, but for them I think it is an excellent presentation.

At work we have been use Ruby for the last 3 years and have found it to be a powerful language that helps make writing software applications fun. And that is important. By providing a powerful language and a rails framework that takes away much of the drudgery of writing code you can create an environment where develops are happy and productive. We are hiring, by the way.

The talk provides a good background on their experience using ruby to manage projects; and how they manage ruby application development projects.

Related: Combinatorial Testing for SoftwareChecklists in Software DevelopmentFuture Directions for Agile Management

The Myth of the Genius Programmer

Nice talk on fear of looking foolish. The speakers discuss the idea that visibility is good. Don’t hide. Make everything visible and the benefit from many people’s ideas. The talk focuses on software development but is true for any work.

“criticism is not evil” – Very true. “At Google we are not allowed to submit code until there is code review.” At the bottom line they are repeating Deming’s ideas: improve the system – people are not the problem, bad systems are the problem. Iterate quickly.

Related: 10x Productivity Difference in Software DevelopmentThe Software Engineering Manager’s LamentRespect for People, Understanding Psychology

Google Innovates Again with Google Wave

Google Wave is a new tool for communication and collaboration on the web, coming later this year. They are developing this as an open access project. The creative team is lead by the creators for Google Maps (brothers Lars and Jens Rasmussen). A wave is equal parts conversation and document. People can communicate and work together with richly formatted text, photos, videos, maps, and more. You really have to watch to understand what it is.

This is a long webcast (1 hour and 20 minutes) and likely will be best only for those interested in internet technology solutions. But it also provides useful insight into how Google is managing the creation of new tools. But the ideas are not explicit (the demo was meant to present the new product Google Wave, not explain the thought behind producing useful technology solutions), so you have to think about how what they are doing can apply in other situations.

For software developer readers they also highly recommended the Google Web Development Kit, which they used heavily on this project. They also have a very cool context sensitive spell checker that can highlight misspelled words that are another dictionary word but not right in the context used (about 44:30 in the webcast). And they discuss using Wave to manage bug tracking and manage information about dealing with bugs (@ 1 hour 4 min point).

Very cool stuff. The super easy blog interaction is great. And the user experience with notification and collaborative editing seems excellent. The playback feature to view changes seems good though that is still an area I worry about on heavily collaborative work. Hopefully they let you see like all change x person made, search changes…

Related: Eric Schmidt on Management at GoogleJoel Spolsky Webcast on Creating Social Web ResourcesGreat Marissa Mayer Webcast on Google InnovationGoogle Should Stay True to Their Management PracticesAmazon Innovation