Archive for the 'Philosophy' Category
November 28th, 2009 by Mark Ramm
Power, dominance, and responsibility are hot button issues which hover over and around every action leaders take like ghosts. And those who ignore them — who wield power without thought, who see only the ends, and ignore the means — put their projects at risk.
I think it’s a truism that there is no single barrier to IT project success more powerful than bad management. There are dozens, if not hundreds, of ways in which bad management directly and indirectly decreases productivity, and undermines even the the possibility of success.
Foucault, is the twentieth century master of uncovering hidden power relationships, and anybody who’s read his masterwork Discipline and Punish will learn a variety of tools to uncover hidden power relationships, and these tools can be immensely valuable in unpacking what’s really going on when a situation “just feels wrong.”
It’s hard to quantify, but knowing this stuff can definitely help you avoid political landmines, and create a safer work environment. But, I still haven’t figured out how to make Foucault palatable and understandable to the average IT manager. ;)
But Naked aggression is easy to spot
On the other hand, you don’t need a sophisticated set of tools for unpacking power relationships to see what’s wrong with some teams. For example, I once worked for a manager who held daily motivational meetings, in which he enumerated every small mistake that any of us could make that might make him look bad, and let each of us know in no uncertain terms that we would be “terminated” if we were seen to have made even the smallest mistake. If we didn’t answer the phone with the right phrase, or try to convince customers that they wanted more expensive products than they needed, or failed to live up to any of thirty different (and sometimes contradictory) arbitrary rules, we were told we would be fired instantly.
Doing the wrong thing may pay off now, but it almost always hurts you later.
I left after less than 6 months, by the time a year was up, only 2 of 20 of the original people on the team were left. But, the manager received a commendation for “running a tight ship.” Things were looking good. Then again, a year later he was fired, because his team just couldn’t keep up, and everyone on the team was so busy not screwing up that the had no time or energy left for the important things they were hired to do.
Dominance games, and pure aggressive pressure helped him meet his daily and weekly goals, but killed him in the long run.
Project managers need to learn to wield power with a light touch.
It’s inevitable that there are power-relationships involved in the context of an important project. If you’re doing things right people are passionate about the project, people want to do the right thing, and people don’t always agree about what the right thing is.
It can be tempting to jump into these disagreements and make decisions — and it can speed up progress in the short term. But be careful, just like the manager who made his short term goals, but lost in the long run, you may end up killing people’s passion, and cutting off discussion before critical information is revealed.
Sure, there are times when a strong good push can help people avoid prolonged and useless discussions, but it’s too easy to take advantage power relationships to avoid difficult but important discussions.
There’s lots more to be said on the subject of power relationships in software development, but I think one of the key things we have to understand is that computer nerds participate in power struggles too, they just do it naively and instinctively. And that leaves us easy prey for those who do it with knowledge, talent, and finesse. And those people are out there and in places where 2 years is a long time, they can get away with it for a surprisingly long time.
P.S. I wrote this post in 2007, almost published it in 2008, and am just now getting around to publishing it. So, please don’t think this is about anything happening to me personally right now, but it is something I keep seeing “around town” and something I think we need to understand better if we are going to stop falling prey to those who understand power politics better than we do and wield them more aggressively, and end up ruining many good projects.
November 24th, 2008 by Mark Ramm
I was reading Jacob Kaplan-Moss’s blog article on “syntactic sugar” and I realized that there’s something sitting just below the surface of what he’s saying, something important, something counter to the standard “software development is an engineering discipline” view of our work.
Jacob rails against those who say the differences between modern computer languages amount to nothing more than “syntactic sugar.” Ultimately he argues that: Syntactic sugar matters.
Sure it makes no “technical” difference but it does make a huge difference — because it changes the way we think about writing software.
I’ll loop back to that in a second, but first a quick detour through another recent blog post:
Eventually you come to realize that in order to truly succeed, you have to write programs that can be understood by both the computer and your fellow programmers.
Of all the cruel tricks in software engineering, this has to be the cruelest…. Even when you’re writing code explicitly intended for the machine, you’re still writing. For other people. Fallible, flawed, distracted human beings just like you. And that’s the truly difficult part.
The thread that ties both of these together is that they highlight the way that people and by people I mean software developers, tend to forget is that code is always two things:
- A series of instructions or declarations processed by a computer.
- A series of instructions or declarations processed by one or more human beings.
Code is a machine construct, but it’s also a social construct. Software engineering is a strange name for our discipline, since the hard work of programming isn’t just getting code that machines can run, but in creating abstractions that allow human beings to learn, understand, and evolve the code over time. We didn’t invent Structured Programming, or Object Oriented Programming because they help the computer understand what we mean — we created them because they provide us with tools to help us as human beings to be able to understand the code we write.
Non-software Engineers aren’t concerned primarily with the practice of communicating complex thoughts and ideas to others. This is a vast oversimplification, but I think it’s fair to say that they are interested in constructing mathematical models of how things things behave, so that they can build stuff that works.
But that’s not what we are, we are creative writers, we invent new ways of thinking about the world, and we try to communicate them to each other every day.
Software Engineers do create incredibly complex systems, and operate under constraints that other writers do not — what we write has two audiences, one human, and one non-human. Writing for the non-human audience alone will result in code that’s incomprehensible to other programmers, but the opposite is also true. Computer programming is hard — and it’s hard for a very specific reason — because it requires thinking like other people, and not thinking like people at all.
Fortunately, the problem is simplified a bit by the fact that other programmers have learned at least somewhat to think like silicon and metal, so you can lean a little bit in that direction and still be understood. But still you have a very exacting, very alien audience, and a very exacting, very human one — and programming languages must be designed to balance the needs of both.
So, perhaps we ought to stop calling ourselves software developers, software architects, or software engineers, and start calling ourselves software writers.
May 14th, 2008 by Mark Ramm
Ocean asks on his blog is data an asset?
Data is certainly not like many other assets, it doesn’t depreciate, you can copy it endlessly, and it’s next to impossible to imagine a commodities market for data. Heck copying the data can either increase it’s value (think “The DaVinchi Code”) or decrease it (think passwords). People don’t pay for data as much as they pay for human attention. You can use data to get attention or you can use attention to collate, assimilate, and otherwise transform raw data into useful information, but either way data needs people to understand and interpret it to become valuable.
So at best:
data + human_understanding == value
Bruce Schenier takes it one step further, calling data the pollution of the the information age.
Data sucks up space, time and human attention. But more than that, data can be parsed, manipulated, and transformed to fit various agendas. And in a world where data about all of us is “owned” by various large corporations, from Amazon, to Google, to Enron, it’s not always clear how that data will be used. Besides which millions of credit card numbers are stolen from various companies who store our data “in good faith.” Data costs money in terms of maintenance, in terms of storage, and in terms of liability. Heck, I know people who work for companies who have an e-mail retention policy — which is really more of a mandatory e-mail deletion policy.
And that assumes that all that data is verifiable true, and that’s definitely not the case. I sold a car once and the new owner didn’t take it to the DMV to get it registered before his friend drove it without a license and got it impounded. And that showed up on my credit report for years. I have a friend who somehow ended up “deceased” even though she’s still very much alive and well.
All of this is to say that as software developers, IT Mangers, and companies in general need to think a lot more about data, and to invest in some better terms for the various different things we call data.
We need to differentiate between raw data, information, and knowledge. We need to help our customers think about the life cycle of the data they want us to capture. We need to educate people about the costs and benefits associated with keeping data, and ultimately we need to follow the mantra:
Think before you store
And if you’re concerned about privacy, and individual liberty, please take a few min and read Bruce’s article.
March 5th, 2008 by Mark Ramm
At CodeMash Neil Ford gave a keynote about polyglot programming, a subject about which I’ve been thinking a lot — and a subject which I have a slightly different (and somewhat more pragmatic) set of opinions than Neil expresses.
But, at the moment I’m hung up on a throw away section of his talk which I think indicates a misunderstanding about the way language and metaphor work. A misunderstanding which is probably particularly common among programmers, but which goes to the heart of why I think software development is so difficult.
Niel takes exception with the notion that software development is software engineering saying something along these lines:
It’s not true. It’s a metaphor. In fact, it’s a ‘tortured’ metaphor. Software and engineering really are different. What we need is to get away from these metaphors, since they cloud the issue, and describe what it is we actually do.
He goes on to say a lot of interesting stuff about how engineering is different than software development, which is of course true. But I think that misses the point a bit. Methaphors aren’t supposed to be flat descriptions of fact. If I say “I’m as tired as a wet dishrag” nobody expects that they could measure my metabolic state against that of the dishrag and determine the “truth” of my statement. It’s true in a very different way. And I’m not just talking about creative language, or artistic merrit. Truth in this case is all about explanatory power.
Natural language is imprecise, analogical, and metaphorical — and after 4 years of philosophy, linguistics, literature, in school and 10 years of software development I’m convinced that these aren’t just surface traits of most language, they are the fundamental constructs from which all human language interactions are built. And, more than that I’m certain that this is actually a good thing, because the world is filled with things that we can only talk about that way. But I’ll get back to that in a second.
First, let’s dive into why I think Neil is wrong, and why I think his error is the kind of error that programmers are particularly prone to fall into.
Programming is both more abstract and more concrete than natural language. As Ocean tells us:
That there are no metaphors in programming, that there is zero ambiguity and every single line of code always has a definite, unambiguous, unarguable, and precise meaning has a very important consequence: integration is extremely difficult. Unlike poets who can take practically anything and throw it at the page and make it stick with a bit of jiggling and handwaving, a programmer must speak in a language that a computer can understand — ultimately, in 1′s and 0′s! And so it’s almost impossible to seamlessly combine programs to create new programs.
Every line of code has a specific well defined meaning. And unlike language that meaning is not the internal subjective representation of the code in the reader’s mind, nor a shared but nebulous social construct. It’s totally external and absolutely quantifiable. Code is defined by the way in which it will be parsed and executed by a pile of silicon.
Natural language is totally different.
One of the most influential philosophers of the 20th century, and very smart dude — Ludwig Wittgenstein — reminds us, it’s very hard to define many words even though everybody knows what they mean. The famous Wittgenstinian example is the word game which applies to things like ring-around-the-rosy, professional football, chess, World of Warcraft, hopscotch, and solitaire. The important thing to notice about this example is some games are played competitively, and others are not, some have well defined rules, others do not, some are frustrating and complex, others are simple and fun, some are professional, and others are done for pure pleasure.
You might suggest that there’s some core idea of amusement involved in all games, but that begs the question what is amusement? How could it be the same for children playing duck-duck-goose, football players at work, and chess masters practicing.
But the most important thing to remember is that even with all these “complications”, it’s obvious to everybody what we mean when we say game — even if they can’t provide an adequate working definition of “game” that actually covers all the things we commonly call games.
As I understand him, Wittgenstein, goes further to suggest that it is the lack of logical rigor, this tendency towards analogy and metaphor, this embrace of ambiguity that makes language useful. I think that’s very much true. Without ambiguity and metaphor we couldn’t communicate complex new ideas, and we couldn’t extend our base of knowledge from one area to another, and we would be entirely unable to communicate anything about huge swaths of human experience at all.
Back to programming. Program languages can’t express love, or disdain, there’s no such thing as irony. There’s no way to say anything meaningful about art or love or spirituality. It’s all concrete instructions that operate in a well known context. So, I see what Ocean is saying when he argues that programming is more concrete than natural languages.
But at the same time, I’m convinced that software development is all about creating systems that encapsulate various kinds of complexity. Another way to say that same thing is that software is all about building up layer upon layer of abstractions, and software debugging is all about the complex process of learning to traveling up and down the “abstraction stack.” And the terminology in software development is all divorced from any easy-real-world referent, “objects” aren’t physical, “stacks” and “heaps” don’t really “take up space” and memory “locations” are only metaphorical. The layers of metaphor requires to say the simplest thing about software development can be enormously daunting. In contrast with natural language it’s so easy to see the relationship between the word “pencil” and the real world object it represents.
So, software development is inherently much more abstract, and is often almost completely divorced from the concrete referents that make up everyday language. Which means it makes lots of sense to say that any kind of reasonable discussion of the the act of programming is ultimately less concrete than most natural language, as is any discussion of the code. And, really what else would you expect from a discipline build around building abstractions and encapsulation of ideas in executable forms.
Ultimately good programmers build up metaphors which provide layers of abstraction which are effective presisely because they offer a non-literal way of talking about the complex things that happen “undernieth” that layer. Take away the metaphors, and you won’t be able to talk about what you do. You won’t be able to explain what you do to other programmers, and you won’t be able to think lucidly about the problem domain and the code at the same time.
All this is the very long way round to saying that programming requires all kinds of mental tricks, and that ultimately talking about writing code is going to require metaphors. With all respect to Niel Ford, the problem is not that we use metaphors, it’s that we don’t understand how to use metaphors well. The more metaphorical our metaphors are, the better, because then they aren’t easily taken for flat descriptions of fact. As far as I am concerned, Software Development is like Engineering, but it’s also like washing windows on a skyscraper, playng chess, or trying to understand what language your teenage daughter is speaking.
Fundamentally I’m convinced that learning to do software development really well is about learning how to communicate really well. And communicating really well means working at the level of metaphor and analogy because the problems, requirements, and users of your system all operate at this level. It also means learning to translate that into code which expresses the metaphors that help people solve their problems in a medium (code) that has zero ambiguity, but to arrange that code into systems built around sensible — and easily communicated — metaphors.