A few comments on software
1. Until recently, I could never understand why good programmers could write terrible software. It is very easy for management to structure things so one person can be productive, but, often, unless they are very careful, when they try to structure things so that three or four people can be productive, they end up creating a context with very little productivity at all.
2. Consultants make terrible employees. Consultants are trained to seem to add value from the first day forward. A software development team is an organism, and a person needs to understand how the organism functions before they can add value. As a consultant, they can make suggestions that the organism can either follow or ignore -- but when they are introduced into the organism, they inevitably have an exaggerated sense of their own importance are fundamentally disruptive.
3. When I started in programming, people who were interested in speed wrote in assembler code. About six years later, a new generation started writing in C. The assembler language programmers said, "there is no way that C can ever be as fast as assembler, C is just a fad". To which the C progammers replied, "while it is theoretically true that C will never contain as few instructions as assembler, C allows people to reach a higher level of complexity and take more things for granted, and as a result, large scale programs will be almost as fast, and five times quicker to develop". Then six years later, the assembler programmers were completely gone, and C++ showed up. Now it was the C programmers turn, and they defended their turf, saying "there is way that C++ can ever be as fast as C". To which, of course, the C++ programmers responded, "that may be true, but C++ allows a higher level of abstraction than C, and consequently, will reduce development time, and since it requires less explicitness, will ultimately run almost as fast as C." Like clockwork, around six years after C++'s ascendancy, C# came along. Now it was the C++ programmers' turn to defend the theoretical speed advantages of their platform over C#, and the C# programmers' turn to extoll the advantages of higher levels of abstraction. This is only interesting because we are now about two years away from c#'s ascendancy, which means that a new paradigm will be coming very soon.
2. Consultants make terrible employees. Consultants are trained to seem to add value from the first day forward. A software development team is an organism, and a person needs to understand how the organism functions before they can add value. As a consultant, they can make suggestions that the organism can either follow or ignore -- but when they are introduced into the organism, they inevitably have an exaggerated sense of their own importance are fundamentally disruptive.
3. When I started in programming, people who were interested in speed wrote in assembler code. About six years later, a new generation started writing in C. The assembler language programmers said, "there is no way that C can ever be as fast as assembler, C is just a fad". To which the C progammers replied, "while it is theoretically true that C will never contain as few instructions as assembler, C allows people to reach a higher level of complexity and take more things for granted, and as a result, large scale programs will be almost as fast, and five times quicker to develop". Then six years later, the assembler programmers were completely gone, and C++ showed up. Now it was the C programmers turn, and they defended their turf, saying "there is way that C++ can ever be as fast as C". To which, of course, the C++ programmers responded, "that may be true, but C++ allows a higher level of abstraction than C, and consequently, will reduce development time, and since it requires less explicitness, will ultimately run almost as fast as C." Like clockwork, around six years after C++'s ascendancy, C# came along. Now it was the C++ programmers' turn to defend the theoretical speed advantages of their platform over C#, and the C# programmers' turn to extoll the advantages of higher levels of abstraction. This is only interesting because we are now about two years away from c#'s ascendancy, which means that a new paradigm will be coming very soon.
Labels: coding, functional programming
0 Comments:
Post a Comment
<< Home