I've always been a proponent of IDE's. I've always believed that the use of the correct IDE to solve a given problem increases productivity by vastly noticeable amounts.
My experience with IDE's in the past has been a tumultuous one. When first starting off in computer science we were introduced to such complex editing tools such as textpad and (shudder) notepad. These text editors gave way to an entire year writing C code in VI, which segued into using more robust editors such as Visual Studio and Eclipse. For in that infancy of IDE knowledge that was all the IDE's were and all they represented; a larger prettier looking text editor.
That was up until about 2 years ago when I took Software Engineering from Phillip Johnson. It was only then that the full scope of this Java language we had been using came into play. Now instead of dealing with five or ten classes we were dealing with hundreds of classes and thousands of method calls. Without the formal training with the Eclipse IDE, specifically tailored to the Java language, I would have been not only lost, but even worse, unproductive.
From that day forward I was sold on IDE's. Code completion and Intellisense were next to godliness, refactoring took just a few clicks, package structure, library imports, code reviews, Eclipse had it all. The future seemed to be a near infinite increase in productivity as I became ever more efficient in using eclipse's keyboard shortcuts and macros.
Then I started my first job in the software development industry, and about a week into it I had a conversation with a coworker which went something like:
Me: "Oh so what IDE do you guys typically use when you're working on projects?"
Coworker: "None."
Me: ".... what???"
Coworker: "I usually code in textpad or notepad and compile it with ant. Most people just pick a single text editor and get really good with it."
Me: ".... what???"
How could it possibly be that in a professional business environment there was no cohesion between developers and the tools that they used. Were they possibly ignorant about how much faster IDE's allow you to program? How was it even possible to be productive?
The IDE Divide, by Oliver Steele, makes the argument that the developer world is divided into two competing camps: The language mavens vs The tool mavens. His argument is basically thus; to the language mavens the real productivity increases occur when more powerful languages are introduced and all IDE's are functionally equivalent text editors. Conversely the tool maven would argue that all languages do functionally the same thing, implement the same methods, accomplish the same goals, and that the real productivity increase comes from the tools used to implement them. He goes on to argue that not only do these camps exist but that they are also mutually exclusive. That developers cannot (or in only the rarest of occasions) be both language and tool mavens simultaneously. This is due to the fact that learning either new developing tools or new languages makes it easier to learn the next developer tool or language that comes along, to the exclusion of the other. Therefore a positive feedback loop exists with respect to the individual camps, making it harder and harder to bridge the functional gap between the two.
Now Oliver Steele is quite obviously a language maven but his argument still stuns me. I've had the luck of having to migrate between two languages which are nearly identical (Java -> C#), but in the past I've noticed some problems when I venture outside of the languages I've formed some level of comfort with, let alone be left alone without my trusty eclipse editor. Luckily Visual Studio provides many of the feature that eclipse does and more.
Now I've seen Visual Studio developers be defined as "IDE Users" rather than software developers, which would be enough to enrage even the most open minded developer. But programming in immense languages like C# or Java is "clearly" (to me at least) easier and more efficiently done within an IDE. So many of the modern high level languages contain such immense API's and so many different libraries that it's seemingly impossible to find the method you're looking for within this giant pile of information.
Has programming become an intractable solution where one has to leaf through API's hundreds of pages long looking for a single method signature? Is it inevitable that the higher level programming languages will evolve to become more and more complex until they eventually become so obscure that they become essentially impossible to use without a specialized IDE?
I sometimes wonder if my coworker was right, are the more advanced IDE's actually useful or are IDE's really useless? Should we stay with the most barebones input possible? Is it even possible to proficiently code in gargantuan languages such as java or C# without the use of a proper IDE?
The alternative according to Oliver Steele (and its a compelling one) is to rely on languages to provide the functionality that we seek. Put the spare development effort into learning the features of new languages and how best to implement them into our projects.
Either way I spent my free time for the last few days finally deciphering how to use emacs. I know I'll be forced to use Visual Studio at the client job site I'm moving to tomorrow, but this article could possibly have changed my whole programming productivity philosophy (alliteration!). I should give it a few weeks to digest before I determine what IDE's really mean to me and how they figure into the grander scheme of being a complete developer.
Thursday, April 24, 2008
Thursday, April 17, 2008
The Requirements vs the Analyst
I always wondered what the "Systems Analyst" job entailed because the job title just sounded so damn cool. Now that I've read Software Requirements by Karl Wiegers I have absolutely no envy for anyone with that job title, in fact I sympathize in the utmost with what must be one of the hardest jobs in the software engineering industry.
In his book Karl Wiegers goes into great depth and detail in an effort to outline the software requirements collection process, which many have touted as being the most important aspect of software engineering due to the fact that the cost in correcting flaws in the requirements left undetected scale exponentially later into the project. It goes into great detail breaking down the groups of users, differing techniques to elicit requirements from either users or managers, as well as the clarification and organization of these requirements into a comprehensible software requirements specification.
I've personally found requirements practice to be the absolute hardest part of software engineering. Not to say that working with other people is either undesirable for the average software engineer, but it is exhausting whenever the effort is to get a large number of people to agree on a single definition or interpretation of a business rule. The greatest tool that I found in Wiegers book was the 'education' concept. If time permits the ability to educate the users, managers, and all groups whom the finished product will be of value, is the greatest one has. Clear communication and education regarding the importance of precise requirements definition goes a long long way towards making the requirements gathering process bearable.
The ideas and processes I had in my mind whenever someone would mention "requirements gathering" involved a bunch of emails, hallway conversations, maybe a lunch or two, and possibly a meeting involving a few people. While Wiegers situations represent the absolute optimal situations given enough time and manpower, his vision of cooperation and communication between users and developers really would be a thing of beauty were anyone able to put it into practice.
In his book Karl Wiegers goes into great depth and detail in an effort to outline the software requirements collection process, which many have touted as being the most important aspect of software engineering due to the fact that the cost in correcting flaws in the requirements left undetected scale exponentially later into the project. It goes into great detail breaking down the groups of users, differing techniques to elicit requirements from either users or managers, as well as the clarification and organization of these requirements into a comprehensible software requirements specification.
I've personally found requirements practice to be the absolute hardest part of software engineering. Not to say that working with other people is either undesirable for the average software engineer, but it is exhausting whenever the effort is to get a large number of people to agree on a single definition or interpretation of a business rule. The greatest tool that I found in Wiegers book was the 'education' concept. If time permits the ability to educate the users, managers, and all groups whom the finished product will be of value, is the greatest one has. Clear communication and education regarding the importance of precise requirements definition goes a long long way towards making the requirements gathering process bearable.
The ideas and processes I had in my mind whenever someone would mention "requirements gathering" involved a bunch of emails, hallway conversations, maybe a lunch or two, and possibly a meeting involving a few people. While Wiegers situations represent the absolute optimal situations given enough time and manpower, his vision of cooperation and communication between users and developers really would be a thing of beauty were anyone able to put it into practice.
Monday, March 31, 2008
Refactoring and Cyclomatic Complexity
"Refactoring" by Martin Fowler is a great book that gives formal definition to a huge mishmash of informal programming procedures and habits. It not only argues the benefits and "whys" of the whole refactoring game (which are often informally understood and championed by many), but also gives formal definition to the types of code decay most often occurring as well as formal definitions and names to the possible solutions.
Fowler lovingly refers to this code decay as "code pungency" or "bad smells in code" when encountered by a developer. However in 1976 Thomas McCabe coined the term "Cyclomatic Complexity" in a paper outlining a software metric used to analyze the complexity of programs. The metric measures the number of linearly independent paths through a given chunk of source code.
"Cyclomatic complexity is computed using a graph that describes the control flow of the program. The nodes of the graph correspond to the commands of a program. A directed edge connects two nodes if the second command might be executed immediately after the first command." [wikipedia]
Basically as the number of conditional statements in a program grows, so do the number of corresponding paths and therefore the graphical representation of the program's control flow. A program with no if/else statements has a single path. Add in one 'if' statement and the number of paths grows to two. One path if the 'if' returns false, and another if it returns true. Any function call including some sort of boolean assessment will fork the program's path, not to mention 'while' and 'switch/case' statements, ad infinitum.
The software metric of cyclomatic complexity serves as a baseline indicator for when a program needs refactoring. From a top level viewpoint the analysis is useless because all programs must include some degree of complexity in order to be useful. Where the measurement become useful is at the method level where methods including some 30 or more linearly independent paths are clearly marked as overly complex and should be scheduled for refactoring.
Several tools exist which do good jobs of measuring this metric:
[JavaNCSS]
[Dependency Finder]
One which includes an excellent visual output of the state of a project's complexity is Panopticode, which also provides visual output of your given level of code coverage as a bonus.
Example: The complexity state of the Cruise Control 2.6 project (hit refresh until it loads).
All in all refactoring is an extremely necessary concept for every programmer to understand, even those who practice it now stand to gain a great deal by understanding why they are doing what they do. I hope to find other refactoring tools to aid in the developmental process soon.
Fowler lovingly refers to this code decay as "code pungency" or "bad smells in code" when encountered by a developer. However in 1976 Thomas McCabe coined the term "Cyclomatic Complexity" in a paper outlining a software metric used to analyze the complexity of programs. The metric measures the number of linearly independent paths through a given chunk of source code.
"Cyclomatic complexity is computed using a graph that describes the control flow of the program. The nodes of the graph correspond to the commands of a program. A directed edge connects two nodes if the second command might be executed immediately after the first command." [wikipedia]
Basically as the number of conditional statements in a program grows, so do the number of corresponding paths and therefore the graphical representation of the program's control flow. A program with no if/else statements has a single path. Add in one 'if' statement and the number of paths grows to two. One path if the 'if' returns false, and another if it returns true. Any function call including some sort of boolean assessment will fork the program's path, not to mention 'while' and 'switch/case' statements, ad infinitum.
The software metric of cyclomatic complexity serves as a baseline indicator for when a program needs refactoring. From a top level viewpoint the analysis is useless because all programs must include some degree of complexity in order to be useful. Where the measurement become useful is at the method level where methods including some 30 or more linearly independent paths are clearly marked as overly complex and should be scheduled for refactoring.
Several tools exist which do good jobs of measuring this metric:
[JavaNCSS]
[Dependency Finder]
One which includes an excellent visual output of the state of a project's complexity is Panopticode, which also provides visual output of your given level of code coverage as a bonus.
Example: The complexity state of the Cruise Control 2.6 project (hit refresh until it loads).
All in all refactoring is an extremely necessary concept for every programmer to understand, even those who practice it now stand to gain a great deal by understanding why they are doing what they do. I hope to find other refactoring tools to aid in the developmental process soon.
Monday, March 17, 2008
The Power of Faith vs The Crushing grip of Reason
A central theme in Lost is the modern personification of the conflict between Faith and Reason. I find this duality to be personified on a day to day basis through my experiences with modern technology and computer science.
The preparation for the upcoming first day at the new job has thus far been an attempt to balance the theoretical with the practical. Reading books such as Code Complete and The Mythical Man Month represent the theory side, while the practical side is a mishmash of Rails hacking and beginner .net, VB and C# tutorials. Should I have faith in my abilities to pickup new technologies and learn as much practical theory as possible, or should reason prevail and should I focus more on learning the physical construction tools personified by languages and IDE's. Of course in practice there is no picking and choosing because practicality must be combined with theory in order to be a complete programmer. So then is there also a balance to be found between faith and reason? Is there a difference??? Or is science just a higher form of religion in who's laws and postulates we steadfastly believe until they are overturned.
Again everything streams toward balance, like sliding down the strings held by some gigantic blindfolded woman of justice onto her scales. I must be empowered to balance myself.
"Trying to find a balance, trying to build a balance." - Slug
The preparation for the upcoming first day at the new job has thus far been an attempt to balance the theoretical with the practical. Reading books such as Code Complete and The Mythical Man Month represent the theory side, while the practical side is a mishmash of Rails hacking and beginner .net, VB and C# tutorials. Should I have faith in my abilities to pickup new technologies and learn as much practical theory as possible, or should reason prevail and should I focus more on learning the physical construction tools personified by languages and IDE's. Of course in practice there is no picking and choosing because practicality must be combined with theory in order to be a complete programmer. So then is there also a balance to be found between faith and reason? Is there a difference??? Or is science just a higher form of religion in who's laws and postulates we steadfastly believe until they are overturned.
Again everything streams toward balance, like sliding down the strings held by some gigantic blindfolded woman of justice onto her scales. I must be empowered to balance myself.
"Trying to find a balance, trying to build a balance." - Slug
Sunday, March 16, 2008
The Mythical Man Month
It's interesting to reflect how much and how little has changed in the past 30 years since The Mythical Man Month was written. The current chapter I just finished reading, regarding the idea that change is an inevitability resonated with me very clearly. The idea that the actual task of any programmer is to realize a vision for a program consumer and deliver to them a semblance of satisfaction rather than any physical program, that the program itself as a physical object only quantizes and represents the customer's desire for change was fascinating.
So not only is change inevitable its also a product one must become accustomed to delivering.
Progress with becoming a prolific rails developer is proceeding at a decent pace. At first its quite unnerving how much work is done in the background via ruby scripts, but at the same time that nervousness is offset by excitement for the power of the rails platform. There is an unbelievable amount of things automatically built into rails, not only interoperability but programming practices as well. DB migrations are akin to version control, the entire MVC architecture. Working on session handling and error correction at the present moment. Proving to be very exciting.
So not only is change inevitable its also a product one must become accustomed to delivering.
Progress with becoming a prolific rails developer is proceeding at a decent pace. At first its quite unnerving how much work is done in the background via ruby scripts, but at the same time that nervousness is offset by excitement for the power of the rails platform. There is an unbelievable amount of things automatically built into rails, not only interoperability but programming practices as well. DB migrations are akin to version control, the entire MVC architecture. Working on session handling and error correction at the present moment. Proving to be very exciting.
Subscribe to:
Posts (Atom)