Over the last decade or so there has been a tremendous change in how software is developed - at least from my perspective.
A decade ago you had to purchase a package like MSDN or set of books on the Apple programming APIs in order to access the knowledge you would need to write code.
For example, the AFS (Apple File Sysetm) interfaces where complicated - there was both synchronous and asynchronous I/O, various B-tree based operations for directories, and so on. I remember owning this particular document and studying it intensely to perform even the simplest of file operations.
At that time MSDN was a bit better - a dozen CDs that you loaded into your computer - and there was some kind of web-like interface that allowed you to search through the various documents.
Operating system APIs like Windows and OS 9 changed very little from release to release - and then only by fairly straight forward additions for better/faster/new hardware.
Major changes, like the introduction of Mac OSX took years. The various Apple shows I recall had whole large sections of trade show booths dedicated just to introducing the new UI.
Production of these documents in those days, like MSDN, were significant efforts - more so for Apple with its printed documentation (there was an electronic versions as well but I recall it being quite tedious to use).
Writing, proof reading, printing, binding, distribution, and so on ensured that the cycle between changes was long.
There were also fewer coders in those days and I think, on average, they had a lot more experience as well.
Today things are very different. I think that in a way there is a lot of negative impact with the new model which is not totally obvious on first inspection.
Today everything is on the web - everything - source code, examples, MSDN, knowledge bases, APIs, new OS releases - everything.
And from a purely developer perspective this is great - when you need info, say how to open a file with stdio/fopen you just go to the web browser and type "fopen" and the answer appears. Need example code, type "fopen sample code" and it appears. Ditto for virtually all .NET and Objective-C-based API operations.
Much of this is supported beyond basic API questions (XML, OS issues, handling complex application issues like color, performance, etc., etc.). For example both www.codeproject.com and www.stackoverflow.com offer free developer environments where you can ask questions about APIs as well as various technical issues and have other developers help you or provide solutions.
But there are some disadvantages as well.
For one companies like Microsoft and Apple create tools to push API changes out the web automatically I am sure. The problem is that usually not everything that needs to be updated is. Apple is notorious for this. Sample code is outdated, won't compile or doesn't use the latest blessed API functions.
API documents can become "out of sync" with each other - document A describing document B which is outdated, and so on.
Again codeproject and stackoverflow are huge helps in these situations.
Another disadvantage is that this allows APIs and hence OS and other things to change more rapidly. Instead of months of writing, testing, printing and publishing about iOS 3.1 to 3.2 I basically just push a button and out goes everything to the web.
But there is no longer any "inertia" in the API. All the old costs, time invested and difficulty in changing things a lot more dicey. "Do we really need to add this or can we just add a new option to that?" So things change more rapidly than ever.
And this can make your investment in code obsolete more quickly.
Another issue is what was once the domain of a third-party application, say file compression, is replaced by OS integration. So the OS is easier to expand over time - adding in convenience for users at the inconvenience of third-party customers.
Easier advancement of the OS APIs creates more backward compatible versions to test. (In the Wolf household we have iOS devices that are operational going back to version 3.X.)
So far a company like Apple, with its so-to-be-release iPhone 5 all of this baggage is following along behind the train. The faster the train goes the more baggage is swept up into the backdraft behind the train.
If the train ever starts to slow down the baggage will catch up and wreak havoc.
In the mean time what can a developer do?
For one thing I think you need a domain where mastery gives you technology well outside what the codeproject's and stackoverflow's give away for free. Many of the comments there say things like "I am writing an app to do X..." where there are thousands of apps already doing X.
So basically you have to do something hard - that no on else is going to likely do anytime soon.
Often combining features in unique was to steer you clear of the me-too developers.
It's also best to use core API functions that have been around a long time rather than iffy ones at the "edge" of the API.
In any case I think that there is a high price for all this - one that we are going to see "come due" in the future.
I am also troubled that none of what I do with iOS, for example, could be done without the internet.
Until recently MSDN still provided disks so if your internet went down you could still work.
No longer. No internet no programming. (Though other things I do don't require as much internet and I can review my own code base for example code as well.)
We have become, at least on the programming side, so dependent on the internet that I am quite sure 90% of what is done could not be without the internet.
To me this is also very troubling...
A decade ago you had to purchase a package like MSDN or set of books on the Apple programming APIs in order to access the knowledge you would need to write code.
For example, the AFS (Apple File Sysetm) interfaces where complicated - there was both synchronous and asynchronous I/O, various B-tree based operations for directories, and so on. I remember owning this particular document and studying it intensely to perform even the simplest of file operations.
At that time MSDN was a bit better - a dozen CDs that you loaded into your computer - and there was some kind of web-like interface that allowed you to search through the various documents.
Operating system APIs like Windows and OS 9 changed very little from release to release - and then only by fairly straight forward additions for better/faster/new hardware.
Major changes, like the introduction of Mac OSX took years. The various Apple shows I recall had whole large sections of trade show booths dedicated just to introducing the new UI.
Production of these documents in those days, like MSDN, were significant efforts - more so for Apple with its printed documentation (there was an electronic versions as well but I recall it being quite tedious to use).
Writing, proof reading, printing, binding, distribution, and so on ensured that the cycle between changes was long.
There were also fewer coders in those days and I think, on average, they had a lot more experience as well.
Today things are very different. I think that in a way there is a lot of negative impact with the new model which is not totally obvious on first inspection.
Today everything is on the web - everything - source code, examples, MSDN, knowledge bases, APIs, new OS releases - everything.
And from a purely developer perspective this is great - when you need info, say how to open a file with stdio/fopen you just go to the web browser and type "fopen" and the answer appears. Need example code, type "fopen sample code" and it appears. Ditto for virtually all .NET and Objective-C-based API operations.
Much of this is supported beyond basic API questions (XML, OS issues, handling complex application issues like color, performance, etc., etc.). For example both www.codeproject.com and www.stackoverflow.com offer free developer environments where you can ask questions about APIs as well as various technical issues and have other developers help you or provide solutions.
But there are some disadvantages as well.
For one companies like Microsoft and Apple create tools to push API changes out the web automatically I am sure. The problem is that usually not everything that needs to be updated is. Apple is notorious for this. Sample code is outdated, won't compile or doesn't use the latest blessed API functions.
API documents can become "out of sync" with each other - document A describing document B which is outdated, and so on.
Again codeproject and stackoverflow are huge helps in these situations.
Another disadvantage is that this allows APIs and hence OS and other things to change more rapidly. Instead of months of writing, testing, printing and publishing about iOS 3.1 to 3.2 I basically just push a button and out goes everything to the web.
But there is no longer any "inertia" in the API. All the old costs, time invested and difficulty in changing things a lot more dicey. "Do we really need to add this or can we just add a new option to that?" So things change more rapidly than ever.
And this can make your investment in code obsolete more quickly.
Another issue is what was once the domain of a third-party application, say file compression, is replaced by OS integration. So the OS is easier to expand over time - adding in convenience for users at the inconvenience of third-party customers.
Easier advancement of the OS APIs creates more backward compatible versions to test. (In the Wolf household we have iOS devices that are operational going back to version 3.X.)
So far a company like Apple, with its so-to-be-release iPhone 5 all of this baggage is following along behind the train. The faster the train goes the more baggage is swept up into the backdraft behind the train.
If the train ever starts to slow down the baggage will catch up and wreak havoc.
In the mean time what can a developer do?
For one thing I think you need a domain where mastery gives you technology well outside what the codeproject's and stackoverflow's give away for free. Many of the comments there say things like "I am writing an app to do X..." where there are thousands of apps already doing X.
So basically you have to do something hard - that no on else is going to likely do anytime soon.
Often combining features in unique was to steer you clear of the me-too developers.
It's also best to use core API functions that have been around a long time rather than iffy ones at the "edge" of the API.
In any case I think that there is a high price for all this - one that we are going to see "come due" in the future.
I am also troubled that none of what I do with iOS, for example, could be done without the internet.
Until recently MSDN still provided disks so if your internet went down you could still work.
No longer. No internet no programming. (Though other things I do don't require as much internet and I can review my own code base for example code as well.)
We have become, at least on the programming side, so dependent on the internet that I am quite sure 90% of what is done could not be without the internet.
To me this is also very troubling...
No comments:
Post a Comment