Posts about programming
agile management blogs Books Career Carnival commentary continual improvement Creativity curiouscat Customer focus customer service Data Deming Economics economy engineering executive pay Google Health care Innovation internet Investing IT Japan John Hunter leadership lean manufacturing Lean thinking management managing people Manufacturing Performance Appraisal Process improvement Psychology Quality tools quote respect for people Six sigma Software Development Statistics Systems thinking tips Toyota Toyota Production System (TPS) webcast
Full tag cloud

Learn to Code to Help Your Career

Posted on February 22, 2012  Comments (0)

I believe there are big benefits to knowing how to code (programing, software development). What is possible for your organization is often significantly impacted by understanding how to properly use software (and create it, coding, when needed). The lack of understanding of software is a significant problem not just for those wanting a job coding (that are available for those with the right skills) but also for those making decisions about what the organization should do.

The profound ignorance (meant not in a pejorative way but in the descriptive way) of software is a significant problem for managers today. The critical role of software in our organizations is only growing. And the importance of understanding software (which coding provides in a way no other learning does) is only increasing. My guess is a decade or two or three from now a understanding of coding will not be nearly as critical for managers. I am just guessing the nature of coding will be significantly changed and not understanding the details needed to code will not be as critical as it is today. Maybe I am wrong about the importance of understanding coding fading over time (it is more a feeling than a chain of logic I can clearly explain easily).

There are many indirect benefits of learning to code. In the same way that those with an education in engineering do very well in their careers overall, even if they take a path where they are no longer engineers a background in coding prepares you well for your career. Actually, similar to engineering, part of this effect may well be those that can graduate with an engineering degree and those that can be employed for several years as a software developer have skills and abilities that would have made them successful even if they didn’t pass through those experiences (still I think, those experiences to add to their success).

Good programmers have a strong tendency to think in ways that those interested in management improvement need (and, sadly, often lack): systems thinking, customer focus, efficiency focused [good coders often hate wasting their time and naturally despise non-value added steps], a willingness to speak up about things that need to be improved, a desire to make a difference, passion for what they do… If you work along side good programmers these traits will be reinforced every day (this was my favorite part of my last job – working with great programmers that pursued these principles and re-enforced my doing so also). Yes there are also things you might have to temper in dealings with non-coders (being a bit kinder/less-direct about perceived failures, for example). Also some coders can be so engaged they expect an unsustainable commitment from peers (this is one of the great benefits of a good agile software development system – a focus on creating an environment for sustainable development [not expecting unreasonable effort/hours on the part of coders]).

Continue reading →

Avoiding Tragedy of the Commons for Software Development

Posted on June 15, 2011  Comments (2)

Kanban and Tragedy of the Commons

The “Tragedy of the Commons” archetype often manifests itself through “Shared Services”, when a small number of people with specific skills, work across different teams. Each team in isolation gets benefit from the Shared Service, but when demand for the service exceeds its capacity, then nobody benefits. At a smaller scale, a team with a low “bus factor”, or a hero, can also suffer from a tragedy of the commons, when too much work is dependent on a single person.

One of the comments on this post suggested that the tragedy of the commons wasn’t an accurate description. My comment:

I think the “tragedy of the commons” analogy works. As long as the users don’t have pay for use (or decide to prioritize) the danger exists for the abuse. So if you have a developer team and everyone just gets to dump tickets on to them and then whine if they don’t get what they want, when they want, I see the analogy as accurate. If people can just treat a resource as though it was suppose to just serve them and the resource is overwhelmed I see that as tragedy of the commons.

There are many ways to manage that problem (some manager deciding the priority for example). Then you may have other problems, but may avoid the tragedy of the commons scenario (in reality this setup is often done, but most don’t accept the prioritizations and just expect the development team to get everything done – which means you don’t avoid the tragedy of the commons problem).
Continue reading →

Assigning Story Points to Bug Fixes

Posted on January 27, 2011  Comments (1)

Agile software development has teams estimate the effort to deliver requests from the product owner. The estimates are done in points (in order to abstract away from hours – as estimates have plenty of variation in how long they will really take). Then the teams capacity (velocity) is determined based on looking at how many points they complete in a “sprint” (a set length, often 2 weeks). Then the product owner can prioritize all of the requests with an understanding of how much effort each is estimated to take and the historical capacity of the development team.

I think it is good to add point estimates to bugs. It may well impact how bugs are prioritized – if it is known to be simple a program manager may say, yes I want these 6 first then… If then know the first 2 are likely to take a bunch of time, they may think, ok, I am not going to get these 4 for awhile… They might just accept that, or may wish to shift more hours to bug fixes this sprint. Or they might say well if it is that big an issue maybe we could do x instead…

In practice I rarely has us estimate emergent bugs we are going to fix in the current sprint, but we do it for bugs that are in the backlog. I sometimes will have us estimate a current bug if I think it is may take significant time – to help determine what we really want to and what the impact may be on the teams output for the sprint. We do not have many emergent significant bugs so it isn’t much of an issue for us.

We do have more difficulty accurately estimating bugs, compared to new stories, but we still provide actionable estimates (they are not perfect, but are usable).

We use agile software development principles at work and they have been a great help in letting us be much more effective than we had been previously. The discussion of priorities and delivery expectations are much improved by such methods I believe. And unrealistic expectations can be reduced. For various reason, without adopting some form of agile/lean… software development methods the common pattern I see is software developers being frustrated by unrealistic expectation of their customers (project managers…) being frustrated by failure to communicate what it is reasonable to expect and status updates. A big part of this is the failure to acknowledge variation (and the related difficulty in estimation). Agile/Kanban… are systems that take the variation into account, and therefore the variation is dealt with as natural instead of leading to bad outcomes for developers and their customers.

Response to Should story points be assigned to a bug fixing story.

Related: Future Directions for Agile Management – Mistake Proofing Deployment of Software Applications – Checklists in Software Development

Managing to Test Result Instead of Customer Value

Posted on October 19, 2009  Comments (5)

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

Posted on September 12, 2009  Comments (3)

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 →

Three Years of Real-World IT Projects In Ruby

Posted on July 16, 2009  Comments (0)

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 Software – Checklists in Software Development – Future Directions for Agile Management

The Importance of Making Problems Visible

Posted on April 2, 2009  Comments (1)

Great, short, presentation webcast by Jason Yip showing the importance of making problems visible. Anyone interested in software development should watch this, and it is valuable for everyone else, also. Great visuals.

Related: Future Directions for Agile Management – Agile Software Development Slideshow – Leading Lean: Missed Opportunity – Information Technology and Management – Curious Cat Micro-financiers – posts on project management – Toyota Institute for Managers

What to Wear to an Interview

Posted on January 3, 2009  Comments (6)

Response to What to Wear for an IT Job Interview?. Is this just a huge bit stereotypical?

Who can blame them for not wanting to bother with their wardrobes? Fashion is fickle. Fashion is expensive. Fashion requires imagination and inspiration, and let’s face it, after a long day spent debugging code or trouble-shooting computer problems, there’s not a lot of creativity left for clothing.

But if there’s one professional occasion when a tech worker should think fashion first, it’s the job interview. CIOs says so. According to research conducted by Robert Half Technology, more than one-third (35 percent) of CIOs surveyed say that IT professionals should sport a suit for a job interview.

I don’t see any harm in wearing a suit and tie or such business attire if you have no other information to go on for IT, or other employees. That advice to candidates is perfectly fine. Asking what is appropriate attire when the interview is set is also a good idea. In fact, that is all you need to take from this post as an interviewee, in my opinion.

Is there any value in you wearing a suit? If so, then not doing so might be a negative. The psychology of what makes people uncomfortable is tricky. And dress is one of those factors that may seem trivial but to differing extents most people base opinions partial on dress (even if they claim they don’t). Some organization with casual dress codes may also look at being too dressed up as a bad sign (out of touch…). Basically they are experiencing the same discomfort with your dress even though most likely they would profess to find those making judgments based on dress to be superficial. The Manager FAQ does a good job of looking at the thought process behind some managers thinking on the topic.

My manager seems to dress funny. Is there any way to impress upon him the pointlessness of corporate appearance?

Your manager is probably aware that, in the abstract, the way she dresses changes nothing. However, part of her job is to interact with other people, and there are rules of etiquette for these dealings. Your manager’s clothing, even when she’s not dealing with other people, is selected in part as a way of telling you that she takes you seriously; it’s just like calling people “sir”. It’s a convention, but that doesn’t mean it’s not a real convention, and your manager is honoring it.

Even if there is no value to doing so there are many people who make judgments on silly factors like clothing.

Now for the most important point for manager’s, from this post, if you evaluate software developers on how they dress please quit and go work in some other line of work. You really don’t have what is needed to manage software developers or system administrators. If you are hiring someone to sit in meetings with MBAs and translate technology to them, then maybe being comfortable in a suit is a valued trait. But if you are hiring someone to create code 90+% of the time the suit is a completely silly measurement of value.

Related: Curious Cat Management Improvement Jobs – IT Talent Shortage, or Management Failure? – Hiring the Right Workers – Google’s Answer to Filling Jobs Is an Algorithm
Continue reading →

A Programmer’s View of the Universe

Posted on December 29, 2008  Comments (0)

A few weeks ago I wrote about integrating information technology and business process management. This post from Steve Yegge is interesting and discusses one reason I find that a good strategy. Programmers, by and large, are good, practical systems thinkers (this is in the management context, thinking of inter-related systems, whatever those systems are – not to be confused with a computer system).

A programmer’s view of the Universe, part 1: The fish

The first thing you notice as a programmer is that it trains you — forces you, really — to think in a disciplined way about complex logic problems. It also gives you a big booster shot of confidence around problem-solving in general. Junior programmers tend to have very high opinions of themselves; I was no exception.

In time, though, programming eventually humbles you, because it shows you the limits of your reasoning ability in ways that few other activities can match. Eventually every programmer becomes entangled in a system that is overwhelming in its complexity. As we grow in our abilities as programmers we learn to tackle increasingly complex systems. But every human programmer has limits, and some systems are just too hard to grapple with.

When this happens, we usually don’t blame ourselves, nor think any less of ourselves. Instead we claim that it’s someone else’s fault, and it just needs a rewrite to help manage the complexity. In many cases this is even true.

Over time, our worldwide computer-programming community has discovered or invented better and better ways ways to organize programs and systems. We’ve managed to increase their functionality while keeping the complexity under control.

But even with such controls in place, systems can occasionally get out of hand. And sometimes they even need to be abandoned altogether, like a dog that’s gone rabid. No matter how much time and love you’ve put into such systems, there’s no fixing them.

Programmers also tend to be active life long learners. This isn’t to say programmers tendencies are all easy to manage. They also are more likely not to accept what most people are willing to accept and can therefore be annoying to some. Now, I happen to think it is good to question conventional wisdom and authority… (which might explain one reason I am annoying), but it also explains why often management find dealing with IT staff annoying. Programmers often refuse to accept management’s belief system, including that the programmers job is just to do whatever the manager tells them to.

Related: A programmer’s view of the Universe, part 2: Mario Kart - What Motivates Programmers? – Reddit, a live view of how software coders think – Explaining Managers to Programmers – A Career in Computer Programming – Programmers – cartoon form – Signs You Have a Great Job … or Not

Gobbledygook

Posted on August 21, 2008  Comments (1)

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

Individual Bonuses Are Bad Management

Posted on August 7, 2008  Comments (1)

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?

In software development, it is very hard to establish the effects of individual contributions and good teamwork is key to the project. Most individual compensation schemes, according to the presentation, absorb vast amounts of management time and resources and leave nobody happy, but team compensation strategies are not easy to implement. Mary presented results from HP’s experiments during the beginning of the nineties, when HP allowed 13 local organisations to experiment with team-incentive plans. All programs were discontinued by the 4th year, due to constant changes to the plans which were needed to distribute available money among the teams and a wide dissatisfaction with the plans by employees.
…
Use profit sharing schemes instead of bonuses to tie people to the organisation goals.
keep in mind the norm of reciprocity — if people feel that they are being treated generously, they will reciprocate it with increased discretionary effort.

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

A Programmers Take on Agile Software Development

Posted on April 6, 2008  Comments (2)

A Case for Agile: Benefits for a Programmer’s Career by Theodore Nguyen-Cao

Through agile development, I’ve been able to deliver working software time and time again. I’ve been exposed to all different aspects of the business. I’ve learn what I like and don’t like to do. I’ve learn what pieces of business I’m interested in and the pieces I don’t care much for. I’ve developed some really good working relationships. I’ve tackled some hard problems. I’ve learned to respond and adapt to the change and turmoil of a startup.

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

10x Productivity Difference in Software Development

Posted on April 2, 2008  Comments (4)

10x Software Development

The original study that found huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1. They found no relationship between a programmer’s amount of experience and code quality or productivity.
…
In years since the original study, the general finding that “There are order-of-magnitude differences among programmers” has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000).

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

Lean, Toyota and Deming for Software Development

Posted on December 2, 2007  Comments (5)

Mary Poppendieck on The Role of Leadership in Software Development, very nice 90 minute webcast:

In this 90-minute talk from the Agile2007 conference, Lean software thought leader Mary Poppendieck reviewed 20th century management theories, including Toyota and Deming, and went on to talk about “the matrix problem”, alignment, waste cutting, planning and standards. She closed by addressing the role of measurement: “cash flow thinking” over “balance sheet thinking”.

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

Joy in Work – Software Development

Posted on November 25, 2007  Comments (11)

This wonderful cartoon shows the all too common despair in work. Software programmers are more likely to really enjoy what they do. There are many reasons for this not the least of which is that they have a fair amount of control over their careers. If they don’t like what they are asked to do, the tools they are asked to work with… they will (more than others) leave for another job. Some managers get frustrated that such people are not willing to put up with the normal bother everyone else seems willing to accept (programmers are often “unreasonable”). But I see an occupation that is more focused on joy in work than most. And creating joy in work is what managers should be worrying about – not getting troublemakers to fall into line.

Why I Program In Ruby (And Maybe Why You Shouldn’t):

Harmony and balance make you feel good. American Rubyists frequently take up all the points of Ruby’s power, expressiveness, and efficiency, but they don’t seem to register the point that Ruby was designed to make you feel good. Even Rubyists who want to explain why Ruby makes them feel good often fail to mention that it was expressly designed for that exact purpose.
…
Don’t program in Ruby because you want power or efficiency. Don’t program in Ruby because you think you “should”, either. Program in Ruby because you like it. And if you don’t like it, don’t program in it.

I enjoy programming using Ruby on Rails.

Related: Hiring Software Developers – posts on improving software development – Don’t ask employees to be passionate about the company! – A Career in Computer Programming – IT Operations as a Competitive Advantage – Reddit, a living example of how software coders think – Focus on Customers and Employees – Signs You Have a Great Job… or Not

IT Operations as a Competitive Advantage

Posted on October 26, 2007  Comments (1)

Operations is a competitive advantage… (Secret Sauce for Startups!)

The example above is the tale of two Web 2.0 startups scaling to 20 systems during their first three months. The first team starts writing software and installing systems as they go, waiting to deal with the “ops stuff” until they have an “ops person”. The second team dedicates someone to infrastructure for the first few weeks and ramps up from there. They won’t need to hire an “ops person” for a long time and can focus on building great technology.

In my experience it takes about 80 hours to bootstrap a startup. This generally means installing and configuring an automated infrastructure management system (puppet), version control system (subversion), continuous build and test (frequently cruisecontrol.rb), software deployment (capistrano), monitoring (currently evaluating Hyperic, Zenoss, and Groundwork). Once this is done the “install time” is reduced to nearly zero and requires no specialized knowledge. This is the first ingredient in “Operations Secret Sauce”.

This is a nice short article discussing startup IT operations. On that topic it is interesting. It is also a good example of how a bit of up front planning can help any organizations. Make plans on realistic options – which often means not expecting everything to be perfect. Expect to have to make do with fewer resources than you would like but are what you will likely have… At work, I use subversion, Ruby on Rails (and practice continuous build and test – I’ll take a look at cruisecontrol.rb) and we are setting up Capistrano. I’ll let our system administrator know about puppet (it looks useful) and take a look at the monitoring options (we have something in place now, I forget the name).

Related: Better and Different – The IT Iceberg Secret – Sub-Optimize – If Tech Companies Made Sudoku

  • Recent Trackbacks

  • Comments