Tag Archives: programming

Learn to Code to Help Your Career

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

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

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.

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 [the broken link was removed] 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

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.

The Importance of Making Problems Visible

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.

What to Wear to an Interview

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.

A Programmer’s View of the Universe

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.

Gobbledygook

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.