Monday, August 30, 2004
Do programmers create intellectual property or merely transform it?
The late mathematician Paul Erdös described a mathematician as "a machine for turning coffee into theorems" (Hoffman, P. The Man Who Loved Only Numbers: The Story of Paul Erdos and the Search for Mathematical Truth. New York: Hyperion, 1998, p. 7)
Once I stopped chuckling at the thought of programmers turning coffee into code, I was siezed by a question: do programmers create intellectual property or merely transform it? There is a marked difference between creating IP ("the creational model") and transforming IP ("the transformational model").
I'm going to hand wave over whether producing software is like making things in a factory. Let's grant that it may be: that doesn't affect whether programmers create or transform IP: if producing software is like a factory, we are now arguing about whether programmers produce the raw materials or simply work the machines.
In this model, there is IP that comes into the factory (perhaps in the form of "requirements" or "design patterns"), it is transformed into bits by some process, and the result is a software product of some value to consumers (by consumers I mean the users, stakeholders, and "product owners", not consumers in the broad market sense).
If programmers create IP, their ideas, designs, and problem solutions are part of the raw materials of the eventual product. If the quality of their ideas is poor, no wonderful practices or processes will save the finished work: poor programmers necessarily produce finished work of low value to its consumers (be they customers or stakeholders).
On the other hand, if programmers merely work the process, transforming IP, then the value of the finished work can be highly insulated from the quality of the programmers, just as minimum wage employees can be a part of a rigidly controlled production process. Poor programmers can produce finished work of acceptable or even high value to its consumers, provided the right process and tools are in place.
I've just talked about the effect of poor programmers in the factory. What about good or even great programmers? What about the mythical hacker? What happens when you use great programmers?
If programmers create IP, then great programmers produce great products. Of course, it is possible to screw this up with incredibly poor process (imagine a factory that collapses on its workforce), but having great programmers drives the value of the finished product on a polynomial or even exponential basis.
On the other hand if programmers merely transform IP, then great programmers will have very little effect on the value of the finished product. While they might finish work a little sooner with fewer defects, these benefits will not translate into higher value for consumers. Their efforts are somehow wasted.
I hear arguments for both models. I see this type of thinking reveal itself in the attitudes recruiters have when offering me candidates: "She has 5 years of C++ and three years of Unix, she has the experience you need."
The implication is that programming is a job with specific tasks and rote methods to be applied, like assembling parts in a factory. Requirements come dribbling down the conveyor belt, you apply the text editor and compiler tools, and the conveyor belt takes your work down the line to QA.
There are voices expressing dissent with the transformational model. One vociferous example is Joel Spolsky. Although he insists that API experience is necessary, he also insists that programmers be smart and get things done.
If I look at companies where programmers work, I see some places where the quality of the programmers (and their management) make vast differences in the value of the product they create. I also see others where the quality of the programmers makes little or no difference.
For example, start-ups need the best people they can find. Forget time to market, you have time to the next round of funding to deal with. People that get it, that can write robust software with high quality in impossibly little time can make or break a start-up, especially in this time when money doesn't rain from the skies.
On the other hand, some ISVs have relatively mature products with modest growth plans. I've heard at least one such company owner saying he'd rather have modestly skilled people with little appetite for solving hard problems. I suspect he's built his business in such a way that adding great people won't double or treble the value of his product.
And if you look at a business that isn't even in the software business, the outlook is dismal for programmers: do you realy think that delivering a big bank's application in half the time really makes a difference? Before you say "every bank wants to save $500,000 on their next big project," ask yourself why so many of them hire IBM Global Services. Not to save money.
Maybe it's because the real value of the project as measured by the people who fund it is measured in political points. And programmers don't generate politicial points, so they can't add value to the stakeholders.
So in the end I think that there's a continuum between programmers who create IP and programmers who transform IP. The difference is driven by characteristics of the environment. Specifically, it isn't "politics" or "culture" at the end of the day. It's the potential for the finished software to add value.
What does this mean if you're a software developer? If you really believe you are great, you must search for an environment where you have the greatest leverage. That's where you're going to make the greatest contribution.
Here are some key questions that have worked well for me in the past when evaluating opportunities to add value:
Once I stopped chuckling at the thought of programmers turning coffee into code, I was siezed by a question: do programmers create intellectual property or merely transform it? There is a marked difference between creating IP ("the creational model") and transforming IP ("the transformational model").
I'm going to hand wave over whether producing software is like making things in a factory. Let's grant that it may be: that doesn't affect whether programmers create or transform IP: if producing software is like a factory, we are now arguing about whether programmers produce the raw materials or simply work the machines.
In this model, there is IP that comes into the factory (perhaps in the form of "requirements" or "design patterns"), it is transformed into bits by some process, and the result is a software product of some value to consumers (by consumers I mean the users, stakeholders, and "product owners", not consumers in the broad market sense).
If programmers create IP, their ideas, designs, and problem solutions are part of the raw materials of the eventual product. If the quality of their ideas is poor, no wonderful practices or processes will save the finished work: poor programmers necessarily produce finished work of low value to its consumers (be they customers or stakeholders).
On the other hand, if programmers merely work the process, transforming IP, then the value of the finished work can be highly insulated from the quality of the programmers, just as minimum wage employees can be a part of a rigidly controlled production process. Poor programmers can produce finished work of acceptable or even high value to its consumers, provided the right process and tools are in place.
I've just talked about the effect of poor programmers in the factory. What about good or even great programmers? What about the mythical hacker? What happens when you use great programmers?
If programmers create IP, then great programmers produce great products. Of course, it is possible to screw this up with incredibly poor process (imagine a factory that collapses on its workforce), but having great programmers drives the value of the finished product on a polynomial or even exponential basis.
On the other hand if programmers merely transform IP, then great programmers will have very little effect on the value of the finished product. While they might finish work a little sooner with fewer defects, these benefits will not translate into higher value for consumers. Their efforts are somehow wasted.
I hear arguments for both models. I see this type of thinking reveal itself in the attitudes recruiters have when offering me candidates: "She has 5 years of C++ and three years of Unix, she has the experience you need."
The implication is that programming is a job with specific tasks and rote methods to be applied, like assembling parts in a factory. Requirements come dribbling down the conveyor belt, you apply the text editor and compiler tools, and the conveyor belt takes your work down the line to QA.
There are voices expressing dissent with the transformational model. One vociferous example is Joel Spolsky. Although he insists that API experience is necessary, he also insists that programmers be smart and get things done.
If I look at companies where programmers work, I see some places where the quality of the programmers (and their management) make vast differences in the value of the product they create. I also see others where the quality of the programmers makes little or no difference.
For example, start-ups need the best people they can find. Forget time to market, you have time to the next round of funding to deal with. People that get it, that can write robust software with high quality in impossibly little time can make or break a start-up, especially in this time when money doesn't rain from the skies.
On the other hand, some ISVs have relatively mature products with modest growth plans. I've heard at least one such company owner saying he'd rather have modestly skilled people with little appetite for solving hard problems. I suspect he's built his business in such a way that adding great people won't double or treble the value of his product.
And if you look at a business that isn't even in the software business, the outlook is dismal for programmers: do you realy think that delivering a big bank's application in half the time really makes a difference? Before you say "every bank wants to save $500,000 on their next big project," ask yourself why so many of them hire IBM Global Services. Not to save money.
Maybe it's because the real value of the project as measured by the people who fund it is measured in political points. And programmers don't generate politicial points, so they can't add value to the stakeholders.
So in the end I think that there's a continuum between programmers who create IP and programmers who transform IP. The difference is driven by characteristics of the environment. Specifically, it isn't "politics" or "culture" at the end of the day. It's the potential for the finished software to add value.
What does this mean if you're a software developer? If you really believe you are great, you must search for an environment where you have the greatest leverage. That's where you're going to make the greatest contribution.
Here are some key questions that have worked well for me in the past when evaluating opportunities to add value:
- Can you quantify the difference between failure, acceptable, and great performance of the project to the company? (Not yourself personally: if the project is high risk, high value, you'll have a great opportunity no matter what role you take)
- Who are the stakeholders in this project (who has the athority to make major decisions)?
- What is the impact of a project failure to the accountabilities of the stakeholders? (You won't get a straight "they'll be fired" answer in a job interview, but you can certainly get a feel for whether they care one way or another.)
The first question establishes whether there is in fact a wide range in expected outcomes of the project. If there is very little range between acceptable and great performance, then you are dealing with people who believe (rightly or wrongly) that programmers trasnform IP and that there is no opportunity to add value other than keeping your seat warm and following orders.
The second and third questions establish whether the factory's roof will stay on. The primary impediment to providing value in an otherwise promising environment in meddling from people who are not committed to the success of the project. And the main reason for a lack of commitment is having the authority to direct the project without being held accountable for the result.
Again, I believe that some factories provide an opportunity for great programmers to create IP, but some do not. And although I've cut myself short, I believe that it is possible to determine whether an environment will allow great programmers to create IP through judicious examination.
Labels: agile
Thursday, August 26, 2004
Small, but significant
This caught my eye:
Phil's comment intrigued me. How often is an idea derided as a trivial advance over existing methods, then we discover that the new idea has just the right combination of power and simplicity to hit the sweet spot? Before AltaVista hyped it, people thought of web search as trivial, a feature at best. Today search has become the primary web navigation experience.
For software creators, the lesson is that we shouldn't hold back from developing our products for fear that they won't "change the world": for all we know, they just might.
In the same way that searching on the Web is a small, but significant departure from Web-based directories, tuple-spaces are a small, but significant departure from message-based pub-sub systems.If you happen to be researching distributed computing, rush over to Linda and Service Oriented Architectures by Phil Windley and find out more about tuple-spaces.
Phil's comment intrigued me. How often is an idea derided as a trivial advance over existing methods, then we discover that the new idea has just the right combination of power and simplicity to hit the sweet spot? Before AltaVista hyped it, people thought of web search as trivial, a feature at best. Today search has become the primary web navigation experience.
For software creators, the lesson is that we shouldn't hold back from developing our products for fear that they won't "change the world": for all we know, they just might.
Tuesday, August 24, 2004
Quiz Answers, plus "Instilling Responsibility"
In Surprise Quiz!, I asked:
In The Talent Myth, Malcolm Gladwell reported "how well people do on a test like this predicts how well they will do in the workplace: good managers pick (2) and (5); bad managers tend to pick (3)".
What I find interesting about this snippet is the relationship between the answers and Agile values: Frequent reporting and personal responsibility are key elements of Scrum, for example. I may be stretching here, but in my experience, one of the most valuable benefits of incremental delivery is the responsibility ethos it creates.
Yes, I know that I wrote an article where I described the benefit of incremental deliver in risk management terms. However, explaining things in dry terms "sells" better than explaining the effect on people, especially to management types. (Managers are often the least people-oriented people in the company.)
Back to incremental development. When a developer has a task, and you explain that they are on the critical path, and you show them a GANTT chart the size of the conference room wall, they're going to shrug their shoulders. Likewise, if you show them a huge baroque architecture and explain their component's place, they're again going to shrug their shoulders.
The twin problems facing us are that any task in a long, architecturally complex project suffers from a lack of urgency and a lack of importance, because over the remaining time in the project lots of things can change.
There's so much uncertainty in any project more than a month long that there's absolutely no way to instill a sense of urgency until about four weeks away from a milestone. And likewise there's absolutely no importance attached to any task until people can see that deliverable functions are going to break if the task isn't completed.
When you have milestones a month or so apart, there's a constant sense of urgency around the dates. Now what about responsibility? Well, if a developer's work is due by the milestone but it's hidden away in some dusty recess of the framework, there's urgency but no importance.
To instill responsibility, you need urgency AND importance. You add the importance by tying the work as closely as possible to functionality in the finished software. When a developer can see that her work must be done in the next four weeks otherwise some function that stakeholders/users/customers want will break, she's motivated. She can take responsibility.
Thus, incremental development. When you identify increments of the finished product to be delivered on a monthly basis, you are making urgency and importance plain and visible. And oh yeas, that buys you "frequent reporting."
Maybe Agile is, at the end of the day, just good management practice.
You have just been promoted to head of an important department in your organization. The previous head has been transferred to an equivalent position in a less important department. Your understanding of the reason for the move is that the performance of the department as a whole has been mediocre. There have not been any glaring deficiencies, just a perception of the department as so-so rather than very good. Your charge is to shape up the department. Results are expected quickly. Rate the quality of the following strategies for succeeding at your new position.
- Always delegate to the most junior person who can be trusted with the task.
- Give your superiors frequent progress reports.
- Announce a major reorganization of the department that includes getting rid of whomever you believe to be "dead wood."
- Concentrate more on your people than on the tasks to be done.
- Make people feel completely responsible for their work.
In The Talent Myth, Malcolm Gladwell reported "how well people do on a test like this predicts how well they will do in the workplace: good managers pick (2) and (5); bad managers tend to pick (3)".
What I find interesting about this snippet is the relationship between the answers and Agile values: Frequent reporting and personal responsibility are key elements of Scrum, for example. I may be stretching here, but in my experience, one of the most valuable benefits of incremental delivery is the responsibility ethos it creates.
Yes, I know that I wrote an article where I described the benefit of incremental deliver in risk management terms. However, explaining things in dry terms "sells" better than explaining the effect on people, especially to management types. (Managers are often the least people-oriented people in the company.)
Back to incremental development. When a developer has a task, and you explain that they are on the critical path, and you show them a GANTT chart the size of the conference room wall, they're going to shrug their shoulders. Likewise, if you show them a huge baroque architecture and explain their component's place, they're again going to shrug their shoulders.
The twin problems facing us are that any task in a long, architecturally complex project suffers from a lack of urgency and a lack of importance, because over the remaining time in the project lots of things can change.
There's so much uncertainty in any project more than a month long that there's absolutely no way to instill a sense of urgency until about four weeks away from a milestone. And likewise there's absolutely no importance attached to any task until people can see that deliverable functions are going to break if the task isn't completed.
When you have milestones a month or so apart, there's a constant sense of urgency around the dates. Now what about responsibility? Well, if a developer's work is due by the milestone but it's hidden away in some dusty recess of the framework, there's urgency but no importance.
To instill responsibility, you need urgency AND importance. You add the importance by tying the work as closely as possible to functionality in the finished software. When a developer can see that her work must be done in the next four weeks otherwise some function that stakeholders/users/customers want will break, she's motivated. She can take responsibility.
Thus, incremental development. When you identify increments of the finished product to be delivered on a monthly basis, you are making urgency and importance plain and visible. And oh yeas, that buys you "frequent reporting."
Maybe Agile is, at the end of the day, just good management practice.
Labels: agile
Monday, August 23, 2004
Surprize Quiz!
Try to answer this question honestly, without trying to "reverse engineer" the correct answer. This isn't a job interview, so you gain the most if you answer correctly and learn something about yourself:
Gladwell's explanation of the results, plus a comparison to my experience with Agile practices, can be found in Quiz Answers, plus "Instilling Responsibility".
You have just been promoted to head of an important department in your organization. The previous head has been transferred to an equivalent position in a less important department. Your understanding of the reason for the move is that the performance of the department as a whole has been mediocre. There have not been any glaring deficiencies, just a perception of the department as so-so rather than very good. Your charge is to shape up the department. Results are expected quickly. Rate the quality of the following strategies for succeeding at your new position.
- Always delegate to the most junior person who can be trusted with the task. This gives juniors an opportunity to learn and develop, raising the overall competence of the group.
- Give your superiors frequent progress reports. This makes your star shine brightly, obtaining support from stakeholders. More importantly, frequent reports are opportunities for frequent feedback, keeping the group's direction in harmony with the organization's goals.
- Announce a major reorganization of the department that includes getting rid of whomever you believe to be "dead wood." Letting go of "C" players is harsh, but it's just as important as hiring people who are "smart" and "get things done." The team is only as strong as the weakest link.
- Concentrate more on your people than on the tasks to be done. Process, process, process. Experienced people know how to do their jobs, but the performance of the group depends on motivating the team and process improvements.
- Make people feel completely responsible for their work. If no-one is accountable for results, there's no accounting for the results you'll obtain :-)
Gladwell's explanation of the results, plus a comparison to my experience with Agile practices, can be found in Quiz Answers, plus "Instilling Responsibility".
Labels: agile
Thursday, August 19, 2004
Agile is an attitude, not a product
Ken Schwaber, creator of the Scrum product development methodology (I reproduce his remarks with permission):
"At XP/AU 2004, I kept hearing the question of how to "sell Agile to the executives." I also heard a lot of discussion about "crossing the chasm," the book about the evolution of products from early adoption to mainstream to late adoption. I got a chance to talk about this with several other people (whose names I will only disclose under duress), and I had the following insight: Agile is not a product. Because it isn't a product, we shouldn't be thinking about selling it, we shouldn't be thinking about it crossing a chasm.
"Thinking of Agile as a product is particularly damaging because it will cause Agile to have the same failure that CMM had when it was viewed as a saleable commodity, as a product. People believed that they could market it and make money from it.
"People who bought it thought that they could then install it, train people on it, and then they would be better. Bob Schatz from Primavera has often pointed out that bringing Agile in is the start of an extensive change process. Deciding on Agile is a commitment to an effort, not the purchase of a solution. I've been concerned for a while about organizations having some success with Agile and deciding to go "Agile" whole hog.
"Their comments reflect a belief that Agile is something that can be implemented, solving a problem, and then they can move on. More to the truth, Agile is a commitment to collaboration, empowerment, respecting each other, courage, flexibility, facing the truth, and trust. It is about people, not products and solutions. I think people who think they can buy an "Agile" product are going to be in for a rude shock.
"I believe that Agile is part of a social revolution to help people learn together to collaboratively figure out how to work and live in an increasingly complex world. Agile is an attitude, not a product. Agile is spirituality, not a religion. We don't have to sell it as a product. We don't have to evangelize it. We simply (and with difficulty) have to live it. People will observe us and envy our joy at work, and quake in fear and be defeated by our productivity. For the old way of doing things doesn't cut it anymore. The Agile way is the appropriate response to our complex times.
"So, be wary, Our culture thinks of everything as a saleable product. It is the metaphor of our consumer society. We will fall back into thinking of Agile as a product over and over, and it will confuse our thinking. Whenever this happens to your neighbor, help them out.
Note that Primavera develop software for managing projects and portfolios in the Classical, Analytical model. And yes, they use Scrum to develop their Classical project management software, because they understand that building software is not like building bridges.
Deb Hartmann pointed out that Ken's remarks have sparked a lively thread on the Scrum Development mailing list. You can read more on line here. Warning: Intrusive Flash advertising.
Labels: agile
Are You a Sharecropper?
"What it comes down to is this: if you want to develop software, you can build for the Web and/or Unix and/or OSS platforms; or alternatively, you can be a sharecropper.
"You’re not a sharecropper, especially not a sharecropper, if you’re building on the Web platform. If you can define your value-add as a series of interactions via a browser, or an interchange of XML messages, nobody can whip the land out from under you."
Another article on the same topic:
"There is all the more reason for startups to write Web-based software now, because writing desktop software has become a lot less fun. If you want to write desktop software now you do it on Microsoft's terms, calling their APIs and working around their buggy OS. And if you manage to write something that takes off, you may find that you were merely doing market research for Microsoft."
"You’re not a sharecropper, especially not a sharecropper, if you’re building on the Web platform. If you can define your value-add as a series of interactions via a browser, or an interchange of XML messages, nobody can whip the land out from under you."
--Tim Bray in The Web’s the Place
Another article on the same topic:
"There is all the more reason for startups to write Web-based software now, because writing desktop software has become a lot less fun. If you want to write desktop software now you do it on Microsoft's terms, calling their APIs and working around their buggy OS. And if you manage to write something that takes off, you may find that you were merely doing market research for Microsoft."
--Paul Graham in "The Other Road Ahead"
Sunday, August 15, 2004
Would you hire yourself as Chief Geek?
Johanna's article describes how to hire a great developer. She explains why experience with a specific language or tool is one of the least important factors in a developer's success. If you're hiring right now, the article has direct, obvious relevance.
"Technical skills are relatively easily taught and learned. How people communicate with one another, their drive, their sense of responsibility, their problem-solving abilities—those skills are valuable parts of each person."
Johanna's article describes how to hire a great developer. She explains why experience with a specific language or tool is one of the least important factors in a developer's success. If you're hiring right now, the article has direct, obvious relevance.
There's another way to read an article like this: with an eye to self-development. What's the best investment of your personal self-improvement time? Do you really need to memorize what a Left Outer Join does? Or would you obtain a greater benefit from putting together a presentation for your local user's group?
Think of yourself as a corporation with a vacancy for "Chief Geek." What is the real job description? Write it down and identify areas where you can get better. The nice thing about this exercise is, if you don't fit the bill right now, your personal corporation is willing to pay for your training and wait for you to qualify.
All you have to do is follow through. And sometimes that means putting aside things that appear to make you more "marketable" like knowledge of Outer Joins and SAX Parsing in favour of softer skills like technical communication and problem solving.
Want more specifics? Follow the link to Johanna's article: she gives specific examples of soft skills that produce better software.
Labels: passion
Friday, August 13, 2004
The Dark Side of the Force
In job interviews, there's a cliché question: "tell me about your weaknesses." It's so over-used, there's a crafty stock answer: "Well, I've been told sometimes I work too hard and I need to slow down. And I'm a bit of a perfectionist, and I have to make sure my colleagues don't resent my pushing for their best work."
In a high-pressure situation, you may prefer to be, as they say, "economical with the truth" when asked a question like this. But privately, everyone has real, actual weaknesses. And every weakness is an opportunity for self-enlightenment and growth.
I don't want to waste your time talking about how I enjoy a leisurely start to the day and have trouble being in the office before 7:00am. Instead, I'm going to generalize and share an observation: every personality trait is simultaneously a strength and a weakness.
For example, I enjoy writing about my feelings on this blog. However, I have to watch the positive to negative ratio: when I spend my time slamming the hoi-polloi, I'm giving in to the negative side of my passion. I'm not alone: there's an entire industry of academics slamming each other's work, so much so that I found this meta-essay: "Considered Harmful" Essays Considered Harmful.
Likewise, I'm passionate about solving hard problems in elegant ways. Bingo! There's a weakness, a hacker mentality, a "he'd rather be slinging Lisp on Linux than grinding Java on Windows NT" attitude. It's true, that's how I usually feel about my work (although I don't use Lisp: a real hacker can write Scheme programs in any language).
By the way, this attitude is not restricted to language weenies. The next time you see a J2EE application with factories, persistence mechanisms, XML-ification of everything, and Inversion of Control, you'll see the handiwork of someone passionate about J2EE architecture.
The trick, I guess, is taking stock of your traits and making sure you minimize the deleterious effects of them while maximizing the benefits. Last year I joined a team working on a J2EE/Oracle application. There were some hard problems to solve, and I was more excited by the 2% of the work that were the hard problems than dismayed by the 98% of the work that was routine.
And there I'll stop. The important thing is to constantly look for the 2% of your world that fuels your passion in a positive way!
In a high-pressure situation, you may prefer to be, as they say, "economical with the truth" when asked a question like this. But privately, everyone has real, actual weaknesses. And every weakness is an opportunity for self-enlightenment and growth.
I don't want to waste your time talking about how I enjoy a leisurely start to the day and have trouble being in the office before 7:00am. Instead, I'm going to generalize and share an observation: every personality trait is simultaneously a strength and a weakness.
For example, I enjoy writing about my feelings on this blog. However, I have to watch the positive to negative ratio: when I spend my time slamming the hoi-polloi, I'm giving in to the negative side of my passion. I'm not alone: there's an entire industry of academics slamming each other's work, so much so that I found this meta-essay: "Considered Harmful" Essays Considered Harmful.
Likewise, I'm passionate about solving hard problems in elegant ways. Bingo! There's a weakness, a hacker mentality, a "he'd rather be slinging Lisp on Linux than grinding Java on Windows NT" attitude. It's true, that's how I usually feel about my work (although I don't use Lisp: a real hacker can write Scheme programs in any language).
By the way, this attitude is not restricted to language weenies. The next time you see a J2EE application with factories, persistence mechanisms, XML-ification of everything, and Inversion of Control, you'll see the handiwork of someone passionate about J2EE architecture.
The trick, I guess, is taking stock of your traits and making sure you minimize the deleterious effects of them while maximizing the benefits. Last year I joined a team working on a J2EE/Oracle application. There were some hard problems to solve, and I was more excited by the 2% of the work that were the hard problems than dismayed by the 98% of the work that was routine.
And there I'll stop. The important thing is to constantly look for the 2% of your world that fuels your passion in a positive way!
Labels: passion
Thursday, August 12, 2004
The 59th Street Bridge Programming Language
Yesterday I learned a new programming language, Groovy. Well, I wrote a simple program in Groovy. I need to do much more with it before I learn to "think in Groovy."
This is important. There's a huge benefit to learning a new programming language, so much so that The Pragramatic Programmers recommend learning a new language every year. Learning a new programming language can be difficult.
Let's be precise: learning to write working programs in a new language is relatively easy, but the first impulse is to think in the style of the languages you already know and write programs using the syntax of the new language. Learning to think in the new language, to write programs in the style of the new language, now that's hard.
If we were talking about human languages, we would be talking about learning to speak a new language idiomatically. It's the idioms you want to learn, not the syntax.
As it is, Groovy has some features that make idioms I already know much, much easier. First-class closures alone make Groovymore expressive than Java (I was going to say "more powerful than," but I want to avoid controversy).
That being said, I want more than just convenience out of a new programming language. I already can compile Lisp programs into bytecodes for the JVM, and I can write my own macros for any Groovy feature I like. What I want are the new idioms.
For example, GPath isn't a feature, it's a way of using closures and Groovy's flexible syntax to make collection expressions that look remarkably declarative (GPath was inspired by XPath, of course). I'm hoping that as I learn Groovy, I learn new idioms.
This is important. There's a huge benefit to learning a new programming language, so much so that The Pragramatic Programmers recommend learning a new language every year. Learning a new programming language can be difficult.
Let's be precise: learning to write working programs in a new language is relatively easy, but the first impulse is to think in the style of the languages you already know and write programs using the syntax of the new language. Learning to think in the new language, to write programs in the style of the new language, now that's hard.
If we were talking about human languages, we would be talking about learning to speak a new language idiomatically. It's the idioms you want to learn, not the syntax.
As it is, Groovy has some features that make idioms I already know much, much easier. First-class closures alone make Groovy
That being said, I want more than just convenience out of a new programming language. I already can compile Lisp programs into bytecodes for the JVM, and I can write my own macros for any Groovy feature I like. What I want are the new idioms.
For example, GPath isn't a feature, it's a way of using closures and Groovy's flexible syntax to make collection expressions that look remarkably declarative (GPath was inspired by XPath, of course). I'm hoping that as I learn Groovy, I learn new idioms.
Wednesday, August 11, 2004
You're Smarter Than You Think
Further to my exhortation to go ahead and write software, I found this on Dan Bricklin's blog:
And that is why you're smarter than you think: you know an awful lot more about what you want to write and why it needs to be written than IBM, Microsoft, Dan Bricklin, Sun, Slashdot, and everyone else put together.
I'll close with some words of advice from George Carlin:
p.p.s. Yes, I blatantly snarfed the headline from Nike. It's about time they got back on track and started using their influence to help people build their self-esteem instead of using one group of disadvantaged brown people to manufacture gaudy baubles for another group of disadvantaged brown people to wear on their feet.
When it comes to the traditional press writing about blogging, I'm reminded of programmers reacting to developments like the spreadsheet when VisiCalc came out. Sure the "programs" people wrote with it, and the "databases" they kept as lists, were not up to the standards of "real" programmers. But "every-person programming and databasing" has proved a boon to society and has not really threatened the profession of "programmer". It has, though, changed the role of programmer by allowing many of the detailed, area-of-expertise-centric applications to be done quickly, effectively, and inexpensively. Likewise, personal online publishing, such as blogging, is providing a means for communicating feelings, facts, experience, and opinions that we're even seeing the benefit of in this first try on a national stage. Bravo!In short, lots of stuff that comes out "sucks" compared to the generally accepted standards. Yet, it sometimes changes the world. If you have an MBA, you can explain the whole thing in terms if "disruptive" forces. Or you could simply say that when someone writes software with a specific person in mind instead of a "market segment" or "analyst" or "their boss" in mind, the software is accessible, valuable, and generally delightful.
And that is why you're smarter than you think: you know an awful lot more about what you want to write and why it needs to be written than IBM, Microsoft, Dan Bricklin, Sun, Slashdot, and everyone else put together.
I'll close with some words of advice from George Carlin:
It's not enough to know what notes to play: you have to know why they need to be played.p.s. Ethan made an amazing suggestion yesterday. When discussing "The Innovator's Solution" with me, he pointed out that the author's focus is defending the entrenched turf, instead of how to be disruptive. His suggestion is that the author's consulting practice is with the lumbering giants that get eaten by the innovative disruptors. Anyways, one very strong possibility is that it's way easier to be disruptive than to defend against disruption. Another reason to be passionate instead of analytical, I say...
p.p.s. Yes, I blatantly snarfed the headline from Nike. It's about time they got back on track and started using their influence to help people build their self-esteem instead of using one group of disadvantaged brown people to manufacture gaudy baubles for another group of disadvantaged brown people to wear on their feet.
Labels: passion
Monday, August 09, 2004
Taking Work Personally
I take software development personally. Developing great software is part of my identity. Doing a fecal, semi-hemispherical (make that "shitty, half-assed") job is, in effect, living my life in a shitty, half-assed way.
Lots of people in our industry jump all over this and talk about how you have to compromise on principles in order to make money, or succeed in company politics. Well, no you don't. Let's get this straight:
Shipping great software is the art of making compromises, of satisfying constraints. However, what makes one project great and another mediocre is the quality of the compromises. Deciding to ship the first Macintosh with 128k of RAM is an example of a high quality compromise. Deciding that it's too time-consuming to fix regressions before the end of the project is an example of a low quality compromise.
The same idea holds for making money, being effective in a team environment, or balancing work and home life. Compromise is the art of the possible, and being passionate is about putting yourself in a position to make high quality compromises.
So when people sigh and tell you that their projects are late because of compromises, they're copping out. The truth is, the people whining about being "reasonable" and "pragmatic"* are actually trying to make themselves feel good about being unprincipled, about having no particular interest in whether their work is great, fair, or poor.
They never had the passion, or they had it but sold out, or it was beaten out of them early. So they tell you how they'd like some principles, but they can't afford any. They're lying to themselves! The worst part of these whimperers is that a few of them secretly want you to fail! It would crumple their world view if you decided to work nights and weekends on some unpaid passionate work and you ended up creating the next friendster, oddpost, or groovy.
On the other hand, I don't mind if they all make tons of money. I'd rather they be happy where they are than sit at their desk all day drinking coffee from a TGIF mug and wishing they were rocking and rolling in a start-up. I've found that the passionate people I know feel the same way: they have an abundance mentality. The only thing I resent about passion-less programmers is their desire to pull us down to their level. It's a herd mentality, and I don't feel particularly bovine.
I'm thinking about this a lot right now. My partner and I are expecting a son this October. A few people who don't know me very well have suggested that now that I'm going to be a father (going to be? as my partner points out, the baby is already here!), I'm going to have to settle down and stop all this passion stuff.
Update:
As if! My feeling is that when you're twenty-one, with no kids and no long-term relationship, you can afford to take a job for the cash. Your life is work, very little sleep, and partying**. Who cares if the nine to five gig is rewarding? But when you're a parent, you're a role model. Now is the very worst time in the world to be working a job that doesn't reflect your values in a deep and meaningful way.
Kids learn from what you are, not what you say or even what you do. No matter what you tell them, they'll grow up to be like you in a fundamental way. Do you think for one moment I plan to have my children learn that work is something you do to pay the bills, but you really don't take any pride in it?
Next I'd have to tell them that you go to school because you need a degree to get a job, instead of an incredible opportunity to learn and meet brilliant, motivated people. Bah!
Okay, time to wrap this up, I've got to get to O----, where my friend Ethan Henry starts today. We're raising the bar another notch! This week I'm interviewing more candidates for a development position, and I'm looking really, really hard for people who feel the same way.
So, thank you for 'listening'. I feel better now, and I hope you do too: I really, truly hope you're going to spend today as passionately as possible. Not throwing a temper tantrum because you have to write your app in Java instead of Lisp, but striving to make those good compromises, the ones that push you closer to shipping a great piece of software.
* I do not mean the pragmatic programmers: those guys have so much passion they practically sweat passion onto every page of their book!
** I know this is old fashioned, but you can get a lot of software written if you avoid anyone who uses the word "party" as a verb :-)
Lots of people in our industry jump all over this and talk about how you have to compromise on principles in order to make money, or succeed in company politics. Well, no you don't. Let's get this straight:
Shipping great software is the art of making compromises, of satisfying constraints. However, what makes one project great and another mediocre is the quality of the compromises. Deciding to ship the first Macintosh with 128k of RAM is an example of a high quality compromise. Deciding that it's too time-consuming to fix regressions before the end of the project is an example of a low quality compromise.
The same idea holds for making money, being effective in a team environment, or balancing work and home life. Compromise is the art of the possible, and being passionate is about putting yourself in a position to make high quality compromises.
So when people sigh and tell you that their projects are late because of compromises, they're copping out. The truth is, the people whining about being "reasonable" and "pragmatic"* are actually trying to make themselves feel good about being unprincipled, about having no particular interest in whether their work is great, fair, or poor.
They never had the passion, or they had it but sold out, or it was beaten out of them early. So they tell you how they'd like some principles, but they can't afford any. They're lying to themselves! The worst part of these whimperers is that a few of them secretly want you to fail! It would crumple their world view if you decided to work nights and weekends on some unpaid passionate work and you ended up creating the next friendster, oddpost, or groovy.
On the other hand, I don't mind if they all make tons of money. I'd rather they be happy where they are than sit at their desk all day drinking coffee from a TGIF mug and wishing they were rocking and rolling in a start-up. I've found that the passionate people I know feel the same way: they have an abundance mentality. The only thing I resent about passion-less programmers is their desire to pull us down to their level. It's a herd mentality, and I don't feel particularly bovine.
I'm thinking about this a lot right now. My partner and I are expecting a son this October. A few people who don't know me very well have suggested that now that I'm going to be a father (going to be? as my partner points out, the baby is already here!), I'm going to have to settle down and stop all this passion stuff.
Update:
As if! My feeling is that when you're twenty-one, with no kids and no long-term relationship, you can afford to take a job for the cash. Your life is work, very little sleep, and partying**. Who cares if the nine to five gig is rewarding? But when you're a parent, you're a role model. Now is the very worst time in the world to be working a job that doesn't reflect your values in a deep and meaningful way.
Kids learn from what you are, not what you say or even what you do. No matter what you tell them, they'll grow up to be like you in a fundamental way. Do you think for one moment I plan to have my children learn that work is something you do to pay the bills, but you really don't take any pride in it?
Next I'd have to tell them that you go to school because you need a degree to get a job, instead of an incredible opportunity to learn and meet brilliant, motivated people. Bah!
Okay, time to wrap this up, I've got to get to O----, where my friend Ethan Henry starts today. We're raising the bar another notch! This week I'm interviewing more candidates for a development position, and I'm looking really, really hard for people who feel the same way.
So, thank you for 'listening'. I feel better now, and I hope you do too: I really, truly hope you're going to spend today as passionately as possible. Not throwing a temper tantrum because you have to write your app in Java instead of Lisp, but striving to make those good compromises, the ones that push you closer to shipping a great piece of software.
* I do not mean the pragmatic programmers: those guys have so much passion they practically sweat passion onto every page of their book!
** I know this is old fashioned, but you can get a lot of software written if you avoid anyone who uses the word "party" as a verb :-)
Friday, August 06, 2004
How to guarantee product failure
How to guarantee product failure from Roger Cauvin lists five fatal mistakes product managers make when writing requirements. It's a fast read, and well worth the time.
The article hit home with me: I'm reviewing our development process right now. Although we do a good job of writing requirements, many of the roadblocks to shipping on time stem from the fact that we then immediately write a specification and the rest of our process is driven by the specification instead of the functional and non-functional requirements.
The article hit home with me: I'm reviewing our development process right now. Although we do a good job of writing requirements, many of the roadblocks to shipping on time stem from the fact that we then immediately write a specification and the rest of our process is driven by the specification instead of the functional and non-functional requirements.
Labels: agile
