|
|
|
|
|
|
Recommended posts: Google Software Engineering - Lean Software Development - If Tech Companies Made Sudoku - Agile Management - Metrics and Software Development - Sub-Optimize part for the Overall Good
Companies seem to think technology is an excuse to provide bad service. Or maybe they don’t need any excuse at all to do so, based on how often they provide bad service. My latest experience with lame pointy haired boss technology came while looking to watch a football game online. Years ago you could listen to any Wisconsin Badger game over the internet - very simple, no special software (just the simple free Real Audio plugin). In subsequent years (just to play a simple audio stream that had worked in previous years they kept requiring upgrades and their ever more complex required software would fail very often). Then the option of listen to online radio broadcasts disappeared altogether (for schools that chose to prevent this anyway).
Now sites that provide video seem incapable of making it a simple process. They chose not to use standard open software solutions. Instead they require you follow their desires to use this or that and then the whole operation fails quite often. Google, no surprise, is an exception (yes it worked prior to Google, they were just smart enough to buy it and not break it). YouTube just works. Can others copy this, idea? Some can, but many phbs decide that really everyone that uses their web sites should be happy to try and download special software and make configuration changes… to get their site working on their personal computers.
The idea that playing video online is solved problem and just making it more and more complex is not a good idea for users no matter if they want to add some bullet points to their boss on why they should get a larger raise this year because they got the engineers to add on some additional new feature that no-one actually wants. Granted This solved problem is a bit lame now, so I am all for improving it. But this should be a process that goes for simpler solutions, not more complex ones. And certainly any timed to the operating system of the end user is too idiotic to consider.
(more…)
I am happy to say our blog has been included in the Top 100 Blogs for Development Managers. The list of blogs is quite impressive, including blogs referenced here previously: Joel on Software (ranked 1st), Coding Horror (2nd), Seth Godin’s Blog (3rd), Paul Graham’s essays (4), Signal vs. Noise (40), Agile Management Blog (43) and Lean Software Engineering (68). The Curious Cat Blog is ranked 41st.
You can read our software development category to get our posts specifically related to that topic. Some specific software development related posts that might give you a flavor for the blog: Software Supporting Processes Not the Other Way Around - Future Directions for Agile Management - Metrics and Software Development - The Defect Black Market. And hopefully many of our other posts will also help software development managers.
These, and similar, rankings don’t mean much, other than according to the criteria used this is now they ranked. Still it is nice to see the Curious Cat Management Improvement blog was nominated and according to the criteria used did so well.
Related: #2 Engineering Blog - Performance without Appraisal - Search Share Data, Checking the ACSI - Best Research University Rankings (2008)
Agile management (agile software development specifically) is something that makes a big difference in my work life. David Anderson consistently provides great ideas on agile management and he does so again in this 90 minute presentation on the future directions for agile. As I learned about agile software development, what I saw was a great implementation of management improvement practices focused on software development that was very compatible with Deming’s management philosophy and lean thinking practices. The Agile manifesto:
The first line can seem to be at odds, but I think in practice it is not - though I admit it may seem that way based on the importance placed on process by Deming (I think you have to read on agile to understand why this is the case). For my use of agile software develop, a highlight of the most important ideas is:
Important concepts addressed by agile management: highly collaborative, risk tolerance, systems thinking, customer interaction, craftsmanship ethic [joy in work], eliminate waste. Great quote from the webcast:
Related: Kanban In Software Engineering - Management Science for Software Engineering - Improving Communication - webcast of David Anderson talking about applying Agile and Deming’s ideas at Microsoft - What is Agile Software Development?
How is this for Gobbledygook? Your home banking access code is expired! You must change your access code at this time. Your access code:
* may be between 4 and 20 characters in length
* must not have been changed within the last 0 days
* may not be one of 3 previously used access codes
* must not repeat the same character more than 0 times
* must not contain 0 characters from previous access code
* must contain at least 0 non-alphabetic character(s)
* may contain the following special characters: !”#$%&()+,-/;<=>?[\]^_`{|}*’
* must contain at least 0 alphabetic character(s)
1) What does “must not have been changed within the last 0 days” mean?
2) How about “must not repeat the same character more than 0 times” ?
3) Or “must not contain 0 characters from previous access code” ?
This kind of stuff is what makes people think computer programmers are crazy. I am sure the software allows users to set criteria. Then this screen is suppose to explain the criteria to users. It seems to me, if the selection is 0, then the correct procedure is to not display anything about it to the user.
Really I am not sure how “must not contain 0 characters from previous access code” is even to be applied if an positive integer were used. I guess you could not allow using any characters from the last access code, which seems crazy to me to begin with, but setting a number seems totally bizarre. I could see setting a requirement that says no repeat of the same sequence of x characters. I think that would probably not work well, but at least I understand what it would mean.
Related: Change Your Name - Bad Software Visual Controls - Complicating Simplicity - web usability resources - Schneier on Security
In, Don’t do what your users say, Hanford Lemoore, provides a nice illustration of why customer focus is important but must be done with care.
This is a great example of looking for the root cause and going to the gemba. You must focus on customers but you must bring thought into how you react. Just doing what they say is likely a bad idea. Ignoring them is also bad. But listening and learning and then adjusting is good.
Related: Pleasing Customers - Confusing Customer Focus - What Could we do Better? - Good Customer Service Example - Find the Root Cause
Gojko Adzic provides a nice post on Mary Poppendieck’s presentation at Agile 2008 on bonus, compensation and motivation: Paying programmers: are bonuses bad and what to do about it?
As usually Mary Poppendieck provides good advice: Mary Poppendieck webcast on Leadership in Software Development. The idea that bonuses are bad management is one of the more difficult management improvement ideas for people to accept. See related posts for much more on the problems with them and what to do instead.
Related: Interview with Mary Poppendieck - The Defect Black Market - Deming on the problems with targets or goals - Incentive Programs are Ineffective - Problems with Bonuses - Measuring and Managing Performance in Organizations
Amazon Simple Storage Service (S3) is a service providing web hosting. The cloud computing solution has been used by many organizations successfully. However the solution has experienced some problems including failing for much of the day on July 20th.
During our post-mortem analysis we’ve spent quite a bit of time evaluating what happened, how quickly we were able to respond and recover, and what we could do to prevent other unusual circumstances like this from having system-wide impacts. Here are the actions that we’re taking: (a) we’ve deployed several changes to Amazon S3 that significantly reduce the amount of time required to completely restore system-wide state and restart customer request processing; (b) we’ve deployed a change to how Amazon S3 gossips about failed servers that reduces the amount of gossip and helps prevent the behavior we experienced on Sunday; (c) we’ve added additional monitoring and alarming of gossip rates and failures; and, (d) we’re adding checksums to proactively detect corruption of system state messages so we can log any such messages and then reject them.
Finally, we want you to know that we are passionate about providing the best storage service at the best price so that you can spend more time thinking about your business rather than having to focus on building scalable, reliable infrastructure. Though we’re proud of our operational performance in operating Amazon S3 for almost 2.5 years, we know that any downtime is unacceptable and we won’t be satisfied until performance is statistically indistinguishable from perfect.
The failure was significant but in my view the advantages of Amazon S3 are still very significant. A huge advantage is how quickly you can scale if needed be. If your application is not hosted on Amazon S3 and it grows enormously you have to physically deal with buying servers, installing them, installing software… All this takes time. On Amazon S3 when you need the bandwidth you can get it, when you don’t need it you don’t have it sitting around unused. In that way it is very lean, it seems to me.
And while server infrastructure failures are bad, for most organizations the option is not Amazon S3 or some solution that is 100% reliable. Currently it is difficult to keep IT infrastructures online and operating and coping with shifting demand… For many situations Amazon S3 seems to be a great resource. They need to keep improving; and they seem to be doing so. Being open and honest about the challenges is a good sign. And improving the system, not blaming a person is another good sign.
Related: Bezos on the Internet Boom - Amazon’s Amazing Achievement - Bezos on Lean Thinking - CERN Pressure Test Failure - 12 Stocks for 10 Years Update (June 2008), Amazon is up 116% in the portfolio since 2005, just behind Google and ahead of Petro China
Paul Graham has some excellent ideas. I have written about some of them previously: Innovation Strategy, What Business Can Learn from Open Source and Google and Paul Graham’s Latest Essay. Y Combinator, which he founded, provides seed funding. Here are some ideas they would like to fund:
Related: Our Policy is to Stick Our Heads in the Sand - Find Joy and Success in Business - Innovative Thinking from Clayton Christensen
David Heinemeier Hansson Talk at Startup School 2008 (Paul Graham’s Y-combinator school). It is helpful to appreciate the importance of some simple ideas. Working on web focused businesses people often get carried away with the huge potential and sometimes lose touch with reality. While the ideas are more obvious when looking at web related business their is plenty here for many companies (the second half might be more helpful for many).
In this talk David does a great job of explaining how 37 signals has chosen to work. They are not concerned with becoming large. They focus on doing what they want to do - creating great software solutions (see: Systemic Workplace Experiments). And on making money to allow them to stay in business.
Some tidbits of advice: create great applications, charge people money, make a profit. Yes to those outside the web world this might seem obvious… He discusses a very similar idea to the idea of 1,000 true fans. He mentions to bring in a $1 million, all you need is 2,000 customers paying $40/month. 37 Signals has done well focusing on small business. Don’t be in such a hurry.
Related: Why is 37signals so arrogant? - Complicating Simplicity - Joy in Software Development - Great Marissa Mayer Webcast on Google Innovation
Well, this doesn’t sound very well thought out. Bonuses often distort behavior. Dr. Deming was not against such targets and bonuses because he thought they would not result in bugs being fixed: Dr. Deming on the problems with targets or goals. It is a question of how that will happen. The system being distorted is the most likely result of any such system.
Everyone worked even harder on the third day. On the fourth day, however, the well had started to dry up. The testers ran, re-ran, and re-ran again the test cases, but they could only find a handful of issues. The developers strained the issue-tracking system, constantly reloading the “unassigned bugs” page and rushing to self-assign anything that appeared.
And then something strange happened at lunch. Instead of going out to eat with his usual teammates, one of the developers went out with a tester. Soon after, another developer went out with another tester. Within a few minutes, almost all of the developers had paired up with testers.
As the developers returned from lunch, they immediately got to work. Instead of scavenging for newly found bugs, they worked on “code refactoring” and new functionality. And as soon as they deployed their changes, testers found bugs — minor, obscure bugs that a developer could easily overlook. And just as quickly as testers found bugs, the developers were able to fix them and re-deploy. By the end of the day, developers and testers had earned an average of $120.
A Case for Agile: Benefits for a Programmer’s Career by Theodore Nguyen-Cao
Most importantly, I still feel I’m growing as a developer. I honestly believe the best thing a developer can do in their career is to always be learning. Everything else will follow.
I am also a strong proponent of agile software development. Information Technology projects have a poor success rate. The best method, I have found, to provide better software solutions is agile development (and I find a grounding in management improvement techniques is useful - customer focus, process improvement, systems thinking, understanding variation, data driven management…). My experience is with custom application development (rather than developing Commercial Off The Shelf software - COTS) for which I think agile is a great fit.
Related: Joy in Work for Programmers - Agile Software Development Presentation - Metrics and Software Development - Management Science for Software Engineering - Programmers at Work - Joel Management
I think these orders of magnitude are not present in between people in many jobs. And I think people’s ability to correctly access who are orders of magnitude better is often faulty. But my experience leads me to believe the difference between exceptional software developers and average (not even below average) is very high. High enough that large increases in pay (say tripling would be sensible). Also accommodating their desires is sensible: freedom from dealing with pointy haired bosses and eliminating other such de-motivators.
While salespeople seen as successful can often be rewarded very well, exceptional software developers rarely are. Most managers don’t seem to be able to grasp that software development is a rare field where such orders of magnitude differences are somewhat common (not one in a million, maybe one in a thousand for a random guess). There are other fields where this is true but most for most fields I do not think this is the case.
In many fields interruptions are costly (and multi-taking is wasteful). In software development those interruptions are often much more costly than in other fields. Peopleware: Productive Projects and Teams is an excellent book on managing software development.
Related: People are Our Most Important Asset - Joy in Software Development - Hiring the Right People - Performance without Appraisal - Measuring and Managing Performance in Organizations
Deming’s 14 points (for software development) by Jamie Dinkelacker (Geo/Maps Engineering Program Manager at Google Inc. Focus on lean principles and agile practices for software development):
A good read. Also a good blog on management improvement ideas and software development (though not very active). See my Deming on Management resource where I try to explain what Dr. Deming actually said and meant and dispel some misconceptions.
Related: Dr. Deming’s 14 Points - Deming’s Ideas at Markey’s Audio Visual - Lean, Toyota and Deming for Software Development - Google: Ten Golden Rules
Three Amazing PHP/MySQL/Perl Developers Now Available - Posting on Craigslist. The url will expire so I included everything but the contact info below (follow the link for contact info).
Yesterday I had to do one of the more difficult things — lay off three of my good friends, all of whom are talented and professional developers.
I’m posting here today in hopes that someone out in the world is looking for some seasoned talent, people who can get things done for you. I will personally recommend all three of these guys, and I’ll detail below each of them. If you are interested, I’m including my phone number. I’ll take your contact information and give it to the person(s) you are interested in, and you can take it from there.
Here goes.
Developer #1
I’ve worked with Developer #1 since 2005. He’s worked for Fortune 500 companies and small startups. His strengths are conceptualizing and implementing complex systems using PHP and MySQL. These systems are not limited to the web, however the web is where most of his work has been for the last few years. During his employment with me, he:
* Designed a complex billing system, complete with audit trails
* Developed a site-wide internationalization system, allowing us to easily translate any phrase on the system to a different language
* Designed and successfully implemented several difficult projects based on half-way decent specifications documents (my fault)
Related: People are Our Most Important Asset - Bad Management Results in Layoffs - Hiring the Right People - Severance Plans to Respect People - Curious Cat Management Improvement Jobs
(more…)
Why is 37signals so arrogant? by Don Norman
I don’t agree. Not compromising leads to solutions that are unlikely to be all things to all people. But with an intelligent and knowledgeable leader will lead to excellent solutions for those that share desires. Now I don’t think this is the best strategy, especially for growth. But it can be an excellent strategy for startup, innovators and those seeking 1,000 fans.
(more…)
Part of the deal is that if 37signals helps you pay, you have to share what you’ve learned with everyone. Not just everyone at 37signals, but everyone who reads our blog. So expect to see some blog posts about these experiences.
…
We just ask people to be reasonable with their spending. If there’s a problem, we’ll let the person know. We’d rather trust people to make reasonable spending decisions than assume people will abuse the privilege by default.
Dr. Deming proposed supporting education of any type for employees (point 13 in the 14 points). That is not often done, but 37 signals is not alone in doing this. Great stuff. Create a great environment for people to work in and you can get great things done. Also good old PDSA at work - try things on a small scale and then institute those experiments that succeed on a wider scale.
Related: Google Experiments Quickly and Often - Vacation: Systems Thinking - Getting and Keeping Great Employees - Joy in Work - Complicating Simplicity - Workplace Management
This is a good post on the systemic drivers of complex processes, take the time to read the whole post. I have a bias is against off the shelf software as it often ends up forcing the process to be designed around the software. And with the amazing power and relative ease of web based applications creating solutions that are specifically designed to the organization are often relatively easy. And yet, as indicated in this article there is often a strong bias in the other direction for buying off the shelf software because it is cheaper and/or faster.
Of course, the decision in each case must be weighed to determine the benefits and cost of the various alternatives. Just remember, if you decide you want simple and flexible, to have your decisions reflect that. I enjoy a telling quote from a software vendor on Toyota’s IT expectations: “it demands that the software or technology be flexible and adapt, often by customizing the code, to its business processes, and not the other way around.” They are right.
Related: Agile Software Development - Complicating Simplicity - Joy in Software Development
IT talent shortage, or management failure?
But if you leave it to some personnel jockey who relies on buzzwords and resumes, you’ll never hire real talent — and it will always seem there is a talent shortage. What’s difficult to understand about that?
Great post. I agree: the main problem is poor management. Dr. Deming kept increasing the percentage of problems due to systemic issues (which are management responsibility to address), he was saying 97% of issues were commons cause problems (from the system) at the end of his life.
So what should managers do? Read the Curious Cat Management Blog and follow the advise in our previous posts, including: Stop Demotivating Employees (IT employees are especially disdainful of pointy haired boss actions that others tolerate more easily) - Signs You Have a Great Job … or Not - Joy in Work for IT - hiring silicon valley style - Bad Management Results in Layoffs
Mary Poppendieck on The Role of Leadership in Software Development, very nice 90 minute webcast:
via, Leadership is not Obsolete for Self-Organizing Teams!
Once again Mary provides a great resource. This is a great overview. Lean Software Development by Mary Poppendieck and Tom Poppendieck is an excellent book on these topics.
Related: articles and webcasts by Mary Poppendieck - posts on software development - more management webcasts
Bringing ‘Lean’ Principles to Service Industries by Julia Hanna
In their research, Staats and Upton document how the use of lean principles affected the workflow at Wipro. The concept of “kaizen,” or continuous improvement, for example, resulted in a more iterative approach to software development projects versus a sequential, “waterfall” method in which each step of the process is completed in turn by a separate worker.
By sharing mistakes across the process, the customer and project team members benefit individually and collectively from increased opportunities to learn from their errors; the project also moves along more quickly because bugs are discovered in the system earlier in the development process.
Iteration is very important. It is important in proper use of the PDSA cycle - many quick iterations are much better than one long slow one. And for software application development it is an excellent strategy.
I think iteration is even more important in software application development than most other areas (for now anyway) because many stakeholders cannot visualize what they need from software. Therefore attempts to force rigid requirements up front fail. No matter how much effort you put in the stakeholder just doesn’t know until they see it and use it - then they can tell you what they want changed. so design a system that works given this - iteration and agile development work very well.
Related: lean thinking articles - Experiment Quickly and Often - Management Consulting (what does the consultants web site show?) - Indian Firms Learning From Toyota (on Wipro posted here in 2005) - posts on improving software development - Not Lean Retailing
Curious Cat Management Improvement Blog © curiouscat.com 2005-2007 powered by WordPress - management improvement jobs
