People smile at me when I tell them that I am still developing in Visual Basic 5 - Maybe you wonder also. (For the case you wonder why I did never do the change to VB 6: It was because of the IDE stability especially when using threads and other lower level Windows API - VB 5 was the better thing here which is another prove that new is not always better. ;-) )
Well, I learned more than 10 programming languages yet but I could hardly say that I can be very productive and efficient with all of them. It is one thing knowing the syntax, a second to know well the standard libraries, a third to know the libraries which are available out there from 3rd parties and a fourth of having your own libraries for the recurring jobs in your realm of work. Further it makes a big difference if you are using a language every day or only occasionally. In general it is better if you have one language that covers all your requirements (e.g. can be used for thick clients and web applications).
It takes years until a system has evolved and reaches it's maximum performance. What for me applies to the programming language used, applies for many other IT infrastructures also.
Let's say, you think of switching from Microsoft Office to Open Office. There will be some migration work and maybe a lot of annoying details (apart from macros that have to be rewritten) that will reduce productivity of the employees in the first step. And therefore you will not do it until it is really worth it.
IT changes fast but this does not mean that you have to be always the early adopter. The primary question should be the costs and the benefit in the long run.
There will be the time when the benefits of a particular change legitimate either big investments (of time and money). In my case switching to Java brings independence from the underlying operating system used for instance, easier network programming, better IDE support when developing web applications and other advantages. However it will take a while until I will reach the same productivity level and development speed as I have in VB where I can reuse libraries that I developed in the last ten years.
Not always big effort is needed for implementing new software products. Just remember that when you start investing more time into a particular product then it should be one that will be used a longer time and make sure that you use it efficiently.
Related posts: IT project costs explosion, The Open Source movement, Ignorance of the different.
2008-10-27
2008-10-23
The good, the bad and the ugly
I am developing software since about 25 years - I started when I was about 10 and in these times there were either the annoying line numbers you had to write on the start of each line and then there were the gosubs and gotos. IDE's weren't existent - just a very basic editor with an interpreter included. Later developing with other languages like C or Clipper I remember school times when compiling and linking took at least 10 minutes for a bigger project. One typo and again waiting - awful!
The good: Nowadays development is wonderful in comparison to the early eightees. There are comprehensive integrated development environments (IDE) with debuggers and refactoring, code and syntax highlightening as well as graphical user interface design (GUI) and much much more. So it is wonderful and therefore I can't understand that some guys still prefer using a text editor and compiler.
The bad: In relation to the older times I mentioned above IT is developing much faster and you could stay learning over and over again never starting getting productive. Programming languages got new structures like delegates, generics and exceptions for example. Let me take the exceptions as an example: I wondered what they are good for when I first heard about them. It was something that about twenty years I could perfectly live without. But I thought that it is only my defense against something new and so I tried to use them in a first few tests. But from my gut feeling I don't like them. Today I found - by accident an article that delivers perfectly the logical reasons against using them (see about Exceptions at Joel on Software). The annoying thing here is that the beginner get told to use them and you read it also in books. Only with a lot of experience and reading a lot of different opinions you can well destinguish which of all that new stuff is really important and what should be avoided or can be ignored.
The ugly: As mentioned not all of the new stuff is really necessary - but hell, I don't have to use all that, I can pick the cool stuff only, isn't it? - Unfortunately some things in IT really developed in an ugly way. One good example is the installation of software: In former times using DOS (that was the OS most people had at home) you only had to copy all the files on the disc to a folder and start it from there. Another example: Restoring the system was basically copying everything back from the backup tape or from the backup disks (the only bad thing was that you had to be a disc jockey). Not only that a simple copy operation is not sufficient any more because some runtime or other precondition is required, in addition to that there is dll or dependency hell. You have either a lot of shared libraries which are maybe slightly incompatible or your program is growing because of the large amount of dependencies of the dependencies and there must be programs written to create the setup program (or package) for putting everything necessary together. Well, and if something gos wrong you start the big search which of the 50 components is the guilty one and then implement a dirty hack workaround because you have no hope that the 3rd party will fix that in time. My only hope here is Linux - I hope that the communities continue developing into the right direction(s).
The good: Nowadays development is wonderful in comparison to the early eightees. There are comprehensive integrated development environments (IDE) with debuggers and refactoring, code and syntax highlightening as well as graphical user interface design (GUI) and much much more. So it is wonderful and therefore I can't understand that some guys still prefer using a text editor and compiler.
The bad: In relation to the older times I mentioned above IT is developing much faster and you could stay learning over and over again never starting getting productive. Programming languages got new structures like delegates, generics and exceptions for example. Let me take the exceptions as an example: I wondered what they are good for when I first heard about them. It was something that about twenty years I could perfectly live without. But I thought that it is only my defense against something new and so I tried to use them in a first few tests. But from my gut feeling I don't like them. Today I found - by accident an article that delivers perfectly the logical reasons against using them (see about Exceptions at Joel on Software). The annoying thing here is that the beginner get told to use them and you read it also in books. Only with a lot of experience and reading a lot of different opinions you can well destinguish which of all that new stuff is really important and what should be avoided or can be ignored.
The ugly: As mentioned not all of the new stuff is really necessary - but hell, I don't have to use all that, I can pick the cool stuff only, isn't it? - Unfortunately some things in IT really developed in an ugly way. One good example is the installation of software: In former times using DOS (that was the OS most people had at home) you only had to copy all the files on the disc to a folder and start it from there. Another example: Restoring the system was basically copying everything back from the backup tape or from the backup disks (the only bad thing was that you had to be a disc jockey). Not only that a simple copy operation is not sufficient any more because some runtime or other precondition is required, in addition to that there is dll or dependency hell. You have either a lot of shared libraries which are maybe slightly incompatible or your program is growing because of the large amount of dependencies of the dependencies and there must be programs written to create the setup program (or package) for putting everything necessary together. Well, and if something gos wrong you start the big search which of the 50 components is the guilty one and then implement a dirty hack workaround because you have no hope that the 3rd party will fix that in time. My only hope here is Linux - I hope that the communities continue developing into the right direction(s).
2008-10-17
The features
To increase the number of items sold companies often try to pack more and more features into their products.
There are two things they often forget during feature-packing:
I already run hot, when my mobile phone takes about 30 seconds to send an SMS message - that was sent much faster on my older models. Not enough, I also had memory leaks so I had to disable some feature. Further it is still that about once a week it needs a reboot - just as a Windows Server (although there is no Windows on that phone).
Although I can write e-mails also with this phone it is slow, few memory, tiny screen to view and typing time is also longer than on a normal keyboard. Once I tried to correct a Word document while on the way. I should have waited until I am again in front of a real computer and read a book in the meantime...
The all-in-one product is a myth. Products that can much usually can do everything a little bit but nothing really good.
So I recommend that you
Remember that for complex things usually more maintenance time and work is required. So beware of the "Total cost of Ownership".
Related posts: IT project costs explosion, IT outsourcing, The hardware.
There are two things they often forget during feature-packing:
- The more complex a system the easier to create confusion and problems.
- If the focus is not kept main original purpose then the item may loose it and hence people are not interested any more.
I already run hot, when my mobile phone takes about 30 seconds to send an SMS message - that was sent much faster on my older models. Not enough, I also had memory leaks so I had to disable some feature. Further it is still that about once a week it needs a reboot - just as a Windows Server (although there is no Windows on that phone).
Although I can write e-mails also with this phone it is slow, few memory, tiny screen to view and typing time is also longer than on a normal keyboard. Once I tried to correct a Word document while on the way. I should have waited until I am again in front of a real computer and read a book in the meantime...
The all-in-one product is a myth. Products that can much usually can do everything a little bit but nothing really good.
So I recommend that you
- carefully think, what are your needs,
- prioritize your needs and
- get a few, reliable products or devices that fit your needs.
Remember that for complex things usually more maintenance time and work is required. So beware of the "Total cost of Ownership".
Related posts: IT project costs explosion, IT outsourcing, The hardware.
2008-10-06
The framework
If somebody would ask me for a contribution to the buzzword bingo game then my 50 cents would be the word "framework".
Companies are building huge frameworks - even big pieces of software - stating that it does provide a framework that enables you to do everything and the workflows, the meta-information and all the rest only has to be configured or implemented.
Well folks, they sell you everything and nothing. Often they even give away their framework for free. What they sell you then is consulting, configuration and implementation.
A piece of software being "only" a framework can make application development easier but a framework without some concrete implementation is worth less than an application (that is maybe less flexible) but actually doing something that is saving you work or opening opportunities you didn't have before.
Nowadays companies do have to maintain several different pieces of software and each new piece introduced has to be flexible so that it can fit in. However, the flexibility can be exaggerated to a level where pieces of software are written that - in theory - could help you to achieve everything, "it just has to be implemented". That makes real sense...
From the technical point of view there is another issue arising with the hype of frameworks when they are stapled together. A larger application can make use of several frameworks and libraries for object serialization, javascript operations (AJAX), database abstraction and many more. For smaller applications making use of many frameworks you get a big bulk of overhead.
Companies are building huge frameworks - even big pieces of software - stating that it does provide a framework that enables you to do everything and the workflows, the meta-information and all the rest only has to be configured or implemented.
Well folks, they sell you everything and nothing. Often they even give away their framework for free. What they sell you then is consulting, configuration and implementation.
A piece of software being "only" a framework can make application development easier but a framework without some concrete implementation is worth less than an application (that is maybe less flexible) but actually doing something that is saving you work or opening opportunities you didn't have before.
Nowadays companies do have to maintain several different pieces of software and each new piece introduced has to be flexible so that it can fit in. However, the flexibility can be exaggerated to a level where pieces of software are written that - in theory - could help you to achieve everything, "it just has to be implemented". That makes real sense...
From the technical point of view there is another issue arising with the hype of frameworks when they are stapled together. A larger application can make use of several frameworks and libraries for object serialization, javascript operations (AJAX), database abstraction and many more. For smaller applications making use of many frameworks you get a big bulk of overhead.
Subscribe to:
Posts (Atom)