I've never liked Hungarian Notation.
No, that's not true. I used my own form of Hungarian Notation in certain C programs (for a certain company). Looking back, I'm not too proud of the programs. They were inexpertly written, and the strange naming conventions did nothing to improve readability.
I'm pretty sure that the programs have been retired.
I have been reading Numerical Methods and FORTRAN Programming, a work from 1964. It describes programming in FORTRAN and lists (obliquely) the rules for variable names and function names in FORTRAN-IV. They are:
- Variable and function names are at most six characters
- Variables of type REAL must begin with a letter in the set A..H, O..Z
- Variables of type INTEGER must begin with a letter in the set I..N
- Function names, if longer than three characters, must end in 'F'
- Variable names cannot end in 'F'
- Function names must begin with letters that follow the variables, for their return types
These are Hungarian Notation rules, or at least very close in thought. The name of the variable (or function) tells you the data type.
They are different from today's Hungarian Notation, which is a convention agreed to by programmers on a team (or for Visual Basic, a whole industry). These rules are baked into the language! In FORTRAN-IV (and I specify the 'IV' part), you don't declare variables, you simply use them, and the name tells the compiler the type.
FORTRAN 77 came out with a number of improvements, the biggest being the logical IF statement and the dropping of mandatory Hungarian Notation. (Oh, you could still use it, but you could override the "I-through-N are integers" rule. And the 'functions must end in F' nonsense disappeared.)
FORTRAN 77 came out thirty years ago. It had the sense to drop Hungarian Notation. When will the rest of us?
Sunday, December 16, 2007
Sunday, October 28, 2007
The latest in programming lanugages
Here is late-breaking news about programming languages. The newest, spiffiest, got-to-have-it language is out. It's called LOLcode.
The name comes from the internet LOLcats, since the language is based on their dialect of English. To my knowledge, this is the only programming language based on English since COBOL.
Here is a sample program:
HAI
VISIBLE "I can has cheezburger?"
I HAS A VAR ITZ 1
VISIBLE "I do count!"
IM IN YR LOOP
VISIBLE VAR
IZ VAR BIGGER THAN 19 O RLY?
YA RLY
GTFO
NO WAI
UP VAR!!1
KTHX
KTHX
KTHXBYE
Like COBOL, all keywords and variable names are in uppercase. And like COBOL, it is meant to be 'readable'. Unlike COBOL, it is meant to be readable by today's up-and-coming internet-savvy, text-phone-using teens, the programmers of tomorrow.
This just may be the next big thing for programming.
Remember, you saw it here first!
The name comes from the internet LOLcats, since the language is based on their dialect of English. To my knowledge, this is the only programming language based on English since COBOL.
Here is a sample program:
HAI
VISIBLE "I can has cheezburger?"
I HAS A VAR ITZ 1
VISIBLE "I do count!"
IM IN YR LOOP
VISIBLE VAR
IZ VAR BIGGER THAN 19 O RLY?
YA RLY
GTFO
NO WAI
UP VAR!!1
KTHX
KTHX
KTHXBYE
Like COBOL, all keywords and variable names are in uppercase. And like COBOL, it is meant to be 'readable'. Unlike COBOL, it is meant to be readable by today's up-and-coming internet-savvy, text-phone-using teens, the programmers of tomorrow.
This just may be the next big thing for programming.
Remember, you saw it here first!
Sunday, October 14, 2007
Heresy 1: Agile is not fast
It may be a heresy, but I will state it:
Agile Development is not faster than waterfall development.
Programmers using Agile techniques are not faster at adding functionality (or requirements, or function points, or any metric you care to use) than developers using waterfall project planning.
As I see it, Agile techniques offer two advantages: consistent levels of quality and the ability to change you mind. With Agile techniques, the 'test before code' practice ensures that you have tests in place and that all new features work, without breaking existing features. The close contact with users and small steps in development (avoiding the large, "think of everything at once and in the beginning" plans of waterfall) lets you decide on the features to add late in development.
Waterfall makes you commit to functionality up front. Typically, the development organization asks the user organization for a list of changes (in order of priority), estimates the effort for each item, estimates available capacity, and then negotiates on the list of items for the release. This list becomes "the commitment" which is then judiciously guarded by the development organization against changes from the user community.
Agile lets you defer "the commitment" and in fact breaks it down into smaller commitments, usually every week or two. The user community can think about new features and postpone the decision to add them. Rather than one big list decided up front, the list starts small and then adds items in small spurts.
But I see nothing in development practices that make developers go faster. (Well, there are benefits from the test-driven practices, but a waterfall-planned project could use test-driven practices for adding features, so there is nothing unique to Agile.) Programmers add code (features, requirements, function points, what-have-you) at the same rate as development.
I believe that Agile Development is perceived as faster than most waterfall projects, from the effects of test-driven development and the ability to change feature sets. I believe that many users are frustrated with the "committed feature set" of waterfall development (probably the day after the commitment) and welcome the time-delayed possibilities of Agile.
But in the end, the number of features added will be about the same.
So it is not actual performance, but perceived performance that makes Agile development seem faster.
Agile Development is not faster than waterfall development.
Programmers using Agile techniques are not faster at adding functionality (or requirements, or function points, or any metric you care to use) than developers using waterfall project planning.
As I see it, Agile techniques offer two advantages: consistent levels of quality and the ability to change you mind. With Agile techniques, the 'test before code' practice ensures that you have tests in place and that all new features work, without breaking existing features. The close contact with users and small steps in development (avoiding the large, "think of everything at once and in the beginning" plans of waterfall) lets you decide on the features to add late in development.
Waterfall makes you commit to functionality up front. Typically, the development organization asks the user organization for a list of changes (in order of priority), estimates the effort for each item, estimates available capacity, and then negotiates on the list of items for the release. This list becomes "the commitment" which is then judiciously guarded by the development organization against changes from the user community.
Agile lets you defer "the commitment" and in fact breaks it down into smaller commitments, usually every week or two. The user community can think about new features and postpone the decision to add them. Rather than one big list decided up front, the list starts small and then adds items in small spurts.
But I see nothing in development practices that make developers go faster. (Well, there are benefits from the test-driven practices, but a waterfall-planned project could use test-driven practices for adding features, so there is nothing unique to Agile.) Programmers add code (features, requirements, function points, what-have-you) at the same rate as development.
I believe that Agile Development is perceived as faster than most waterfall projects, from the effects of test-driven development and the ability to change feature sets. I believe that many users are frustrated with the "committed feature set" of waterfall development (probably the day after the commitment) and welcome the time-delayed possibilities of Agile.
But in the end, the number of features added will be about the same.
So it is not actual performance, but perceived performance that makes Agile development seem faster.
Wednesday, October 3, 2007
What Techies want
Techies are not so hard to understand. Their wants are simple. Christine Comaford, back in the 1980s, listed four things that techies want:
1) Lavish praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza
4) Some money
I liked this list so much I stole it. I repeat it when I can (always giving Ms. Comaford-Lynch credit).
I also modified this list. My modified version is:
1) Lavish, genuine praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza, although perhaps not for dinner every night
4) Some money
People (non-techie people, that is) are surprised at the position of money. And at the qualifier "some". Techies don't want lots and lots of money. In general, they want enough to live in reasonable quarters, pay for things like food and the phone bill, and have enough left over for books, music, games, and a few other vices.
It's not that hard.
1) Lavish praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza
4) Some money
I liked this list so much I stole it. I repeat it when I can (always giving Ms. Comaford-Lynch credit).
I also modified this list. My modified version is:
1) Lavish, genuine praise
2) Fun projects to work on and fun tools to work with
3) Free beer and pizza, although perhaps not for dinner every night
4) Some money
People (non-techie people, that is) are surprised at the position of money. And at the qualifier "some". Techies don't want lots and lots of money. In general, they want enough to live in reasonable quarters, pay for things like food and the phone bill, and have enough left over for books, music, games, and a few other vices.
It's not that hard.
Sunday, September 23, 2007
Lock-in is the new lock-out
What is 'lock-in'? Lock-in is the use of proprietary formats as a way of retaining customers. Microsoft does this with their MS-Word and MS-Excel file formats. The formats are closed, known only to Microsoft and those companies they choose to include in partnerships. But Microsoft is only one example, and I'm not going to pick on Microsoft.
The problem is not limited to Microsoft, and not with Microsoft. The problem is the idea: Lock customer data in a format (or a "prison cell") where only the software from one vendor can read it (has the "key" to unlock the "cell").
So passe! So twentieth century!
Locking data inside an application relies on trust (or naivete) on the part of the customer. A long time ago, IBM salespeople would meet with businessmen, review their use of IBM mainframes and peripherals, and then decide on the next 'generation' of equipment that the business should use. The IBM sales team decided this, alone, not with the customer company. They would then present their recommendations to the customer and frequently the customer would buy everything recommended. The customer trusted the IBM team to recommend the right equipment. (And probably did not have the expertise to disagree.)
Those days are gone. Today, customers for mainframes are savvy and have a keen eye on expenses. And they can pick from a variety of mainframe vendors. When your customers have options, they will pick those options that favor them.
Customers don't (necessarily) want open standards... but they do want to move information from one place to another. Whether documents, spreadsheets, databases, or .mp3 files, customers want to use their data in multiple places, with multiple applications. And they become frustrated when they cannot.
Locking data into a proprietary format can be done when you have a monopoly or near-monopoly. Microsoft has done well with its Office suite, where data is locked inside difficult, if not opaque, file formats. And while some groups have had modest success reverse-engineering those formats, there is always the spectre of incompatibility. The lure of 'file format compatibility' has kept many customers in the Microsoft camp. But a good portion of them chafe. They will jump ship when a new option appears on the horizon. (Some of them will jump simply to get away from the oppressor. But the reason doesn't matter... they leave.)
Microsoft is big and has a commanding presence in the market, and even they have felt the pressure to open their formats. Smaller companies, or companies with smaller market shares (and those companies without 'market power') would be well advised to stay away from the 'lock-in' strategy. It is better to compete on features, usability, and performance.
Of course, that's harder than designing an opaque file format. But I didn't say it would be easy.
The problem is not limited to Microsoft, and not with Microsoft. The problem is the idea: Lock customer data in a format (or a "prison cell") where only the software from one vendor can read it (has the "key" to unlock the "cell").
So passe! So twentieth century!
Locking data inside an application relies on trust (or naivete) on the part of the customer. A long time ago, IBM salespeople would meet with businessmen, review their use of IBM mainframes and peripherals, and then decide on the next 'generation' of equipment that the business should use. The IBM sales team decided this, alone, not with the customer company. They would then present their recommendations to the customer and frequently the customer would buy everything recommended. The customer trusted the IBM team to recommend the right equipment. (And probably did not have the expertise to disagree.)
Those days are gone. Today, customers for mainframes are savvy and have a keen eye on expenses. And they can pick from a variety of mainframe vendors. When your customers have options, they will pick those options that favor them.
Customers don't (necessarily) want open standards... but they do want to move information from one place to another. Whether documents, spreadsheets, databases, or .mp3 files, customers want to use their data in multiple places, with multiple applications. And they become frustrated when they cannot.
Locking data into a proprietary format can be done when you have a monopoly or near-monopoly. Microsoft has done well with its Office suite, where data is locked inside difficult, if not opaque, file formats. And while some groups have had modest success reverse-engineering those formats, there is always the spectre of incompatibility. The lure of 'file format compatibility' has kept many customers in the Microsoft camp. But a good portion of them chafe. They will jump ship when a new option appears on the horizon. (Some of them will jump simply to get away from the oppressor. But the reason doesn't matter... they leave.)
Microsoft is big and has a commanding presence in the market, and even they have felt the pressure to open their formats. Smaller companies, or companies with smaller market shares (and those companies without 'market power') would be well advised to stay away from the 'lock-in' strategy. It is better to compete on features, usability, and performance.
Of course, that's harder than designing an opaque file format. But I didn't say it would be easy.
Sunday, August 19, 2007
No simple answers
Which is the better deal: a 9-inch pizza for $9 or a 12-inch pizza for $14?
The gut-reaction answer is the 9-inch pizza. But that answer is incorrect.
The correct answer is the 12-inch pizza.
Assuming that the pizzas are round, the 9-inch pizza has an area of (almost) 64 square inches and a cost of $0.14 per square inch. The 12-inch pizza has an area of 113 square inches and a cost of $0.12 per square inch.
Why is it easy to pick the wrong answer? Because the two options were presented in terms of diameter, but the value is measured in area. To get the proper answer, you must convert the presented information into the form used for the calculation of value.
Or, in another view, the information presented was 'features' (a 9-inch pizza) and not 'benefits' (total area of pizza). Features are not (necessarily) benefits. Features are attributes of the product. Benefits are things that provide value. They are not the same. One can be converted to the other, provided you know the formula. For pizza, this is an easy conversion. For other items (like software) the conversion can be harder to define.
You knew I was going to get to software at some point, right?
When selecting software, it is easy to pick the one with the most features, on the assumption that it is better than the others. Or at least it will do everything that the other packages will do.
Or it is easy to pick the one with the lowest cost, on the assumption that the possible selections are roughly the same.
Both methods are easy.
And both methods rely on assumptions. Which means they may provide a good result, or may not, depending on the truth to the assumptions.
If you are selecting software, you must understand how the software will be used and how it provides value. You must know the benefits of the software, not merely the features. Only then can you select the best software for your needs.
Knowing how you will use the software is a hard task. It means understanding how people use the software today. It means predicting future use of the software.
It's much easier to simply pick the package with the lowest price. Or the most features.
But the the best solution may not have the lowest price may, nor the most features. Even when they coincide. As an example, consider air travel. If I had to travel from the East coast to the West coast, and were presented with two options: Continental for $299 and Southwest for $349, with departure and arrive times about the same, and Continental offering a free movie and meal on board, I would pick the Southwest flight. (Southwest offers no in-flight movie and provides at most peanuts.)
"Why?", I hear people ask. The Continental flight has a lower cost *and* more features (and other aspects are equal). The cost is better and the feature list is better. In this case isn't Continental the better choice?
The answer is that Southwest is the better choice, because it provides more value. Remember, features are not directly equivalent to value. The features that Continental provides have no value for me: I've eaten their in-flight meals and I find that a sandwich and piece of fruit from the local shop is better.
I've also seen their arrangements for in-flight movies and find it has negative value. Continental uses little flip-down screens that show the movie in multiple locations on there planes; there is no escape from it. A good movie is tolerable but a bad movie is torture. On average, the movie is a disincentive to use Continental. The extra $50 for the Southwest flight is worth it to *not* have a movie inflicted upon me.
There are no simple answers. It's all about the benefits, and identifying the meaningful benefits is work. The simple answers are often wrong.
Which means that the 9-inch pizza might be the better deal, when you are not that hungry.
The gut-reaction answer is the 9-inch pizza. But that answer is incorrect.
The correct answer is the 12-inch pizza.
Assuming that the pizzas are round, the 9-inch pizza has an area of (almost) 64 square inches and a cost of $0.14 per square inch. The 12-inch pizza has an area of 113 square inches and a cost of $0.12 per square inch.
Why is it easy to pick the wrong answer? Because the two options were presented in terms of diameter, but the value is measured in area. To get the proper answer, you must convert the presented information into the form used for the calculation of value.
Or, in another view, the information presented was 'features' (a 9-inch pizza) and not 'benefits' (total area of pizza). Features are not (necessarily) benefits. Features are attributes of the product. Benefits are things that provide value. They are not the same. One can be converted to the other, provided you know the formula. For pizza, this is an easy conversion. For other items (like software) the conversion can be harder to define.
You knew I was going to get to software at some point, right?
When selecting software, it is easy to pick the one with the most features, on the assumption that it is better than the others. Or at least it will do everything that the other packages will do.
Or it is easy to pick the one with the lowest cost, on the assumption that the possible selections are roughly the same.
Both methods are easy.
And both methods rely on assumptions. Which means they may provide a good result, or may not, depending on the truth to the assumptions.
If you are selecting software, you must understand how the software will be used and how it provides value. You must know the benefits of the software, not merely the features. Only then can you select the best software for your needs.
Knowing how you will use the software is a hard task. It means understanding how people use the software today. It means predicting future use of the software.
It's much easier to simply pick the package with the lowest price. Or the most features.
But the the best solution may not have the lowest price may, nor the most features. Even when they coincide. As an example, consider air travel. If I had to travel from the East coast to the West coast, and were presented with two options: Continental for $299 and Southwest for $349, with departure and arrive times about the same, and Continental offering a free movie and meal on board, I would pick the Southwest flight. (Southwest offers no in-flight movie and provides at most peanuts.)
"Why?", I hear people ask. The Continental flight has a lower cost *and* more features (and other aspects are equal). The cost is better and the feature list is better. In this case isn't Continental the better choice?
The answer is that Southwest is the better choice, because it provides more value. Remember, features are not directly equivalent to value. The features that Continental provides have no value for me: I've eaten their in-flight meals and I find that a sandwich and piece of fruit from the local shop is better.
I've also seen their arrangements for in-flight movies and find it has negative value. Continental uses little flip-down screens that show the movie in multiple locations on there planes; there is no escape from it. A good movie is tolerable but a bad movie is torture. On average, the movie is a disincentive to use Continental. The extra $50 for the Southwest flight is worth it to *not* have a movie inflicted upon me.
There are no simple answers. It's all about the benefits, and identifying the meaningful benefits is work. The simple answers are often wrong.
Which means that the 9-inch pizza might be the better deal, when you are not that hungry.
Sunday, August 5, 2007
Two-cycle development
I have been working with software for a while now (more years than I care to mention) and I have found that I work in two different modes. The first mode is 'creating software' and the second is 'refining software'.
The 'creating' mode is when I add new features to a program. It could be at the very beginning of a development effort, when there are no features in a program, or it could be later, when the software is 'mature' (whatever that means).
The 'refining' mode is different. It is not adding features, but changing the software to perform the same feature set but with better internal design. This might mean replacing a sort routine with a better sort routine, refactoring a class for better organization, or changing a program for better division of labor. The important part in this phase is that no features change -- the program works just as before. The internals are different, the externals are the same.
These two modes of thought are, in my mind, part of the basic human psyche. At some times, our minds want to create. At other times, our minds want to re-arrange that which we have created. I consider both modes creative, although different types of creativity.
I think that two-cycle development is necessary. It's necessary because we don't get the design of the program right the first time. Oh, we get something that works, but that doesn't mean the design is right. Despite all of the planning, all of the analysis, and all of the reviews, we build software poorly. Refactoring allows us to examine our construct, think about the design, and figure out better ways to do the job.
Two-cycle development leverages our 'Monday morning quarterbacking' talents (even for our own work), and is possible with automated tests. The ability to re-arrange, to experiment, to try new things, is much easier with a complete set of tests. You need the tests to verify your experiment. Without automated tests, you must rely on manual tests, and manual tests are hard to perform. Since they are hard to perform, programmers tend to skip them. And when programmers skip the tests, they miss errors. After a few experiments in re-organizing code without tests (and a few introduced defects) programmers learn to avoid refactoring operations.
Without automated tests, development tends to avoid refactoring.
Without the refactoring, we use our initial, poor designs. While they work, the designs fail over time. And they often fail in slow ways. Failures occur not in spectacular collapses, but in slow decay. Any system built without refactoring gradually accumulates poor designs, and these poor designs increase the future work on the program. Over time, changes to the program take more time and effort, and the number of defects per change increases. The program gets tangled and hard to understand. Eventually, development grinds to a halt as each change introduces more defects than improvement.
To prevent this 'slow death by poor design', we must allow (and plan for) refactoring. And to refactor the program, we must do to things: allow developers time for refactoring and provide the tests to verify that the changes work. Without these, the program accumulates 'cruft' and becomes harder to maintain.
The 'creating' mode is when I add new features to a program. It could be at the very beginning of a development effort, when there are no features in a program, or it could be later, when the software is 'mature' (whatever that means).
The 'refining' mode is different. It is not adding features, but changing the software to perform the same feature set but with better internal design. This might mean replacing a sort routine with a better sort routine, refactoring a class for better organization, or changing a program for better division of labor. The important part in this phase is that no features change -- the program works just as before. The internals are different, the externals are the same.
These two modes of thought are, in my mind, part of the basic human psyche. At some times, our minds want to create. At other times, our minds want to re-arrange that which we have created. I consider both modes creative, although different types of creativity.
I think that two-cycle development is necessary. It's necessary because we don't get the design of the program right the first time. Oh, we get something that works, but that doesn't mean the design is right. Despite all of the planning, all of the analysis, and all of the reviews, we build software poorly. Refactoring allows us to examine our construct, think about the design, and figure out better ways to do the job.
Two-cycle development leverages our 'Monday morning quarterbacking' talents (even for our own work), and is possible with automated tests. The ability to re-arrange, to experiment, to try new things, is much easier with a complete set of tests. You need the tests to verify your experiment. Without automated tests, you must rely on manual tests, and manual tests are hard to perform. Since they are hard to perform, programmers tend to skip them. And when programmers skip the tests, they miss errors. After a few experiments in re-organizing code without tests (and a few introduced defects) programmers learn to avoid refactoring operations.
Without automated tests, development tends to avoid refactoring.
Without the refactoring, we use our initial, poor designs. While they work, the designs fail over time. And they often fail in slow ways. Failures occur not in spectacular collapses, but in slow decay. Any system built without refactoring gradually accumulates poor designs, and these poor designs increase the future work on the program. Over time, changes to the program take more time and effort, and the number of defects per change increases. The program gets tangled and hard to understand. Eventually, development grinds to a halt as each change introduces more defects than improvement.
To prevent this 'slow death by poor design', we must allow (and plan for) refactoring. And to refactor the program, we must do to things: allow developers time for refactoring and provide the tests to verify that the changes work. Without these, the program accumulates 'cruft' and becomes harder to maintain.
Subscribe to:
Posts (Atom)