Tuesday, March 30, 2004
Security is great until it breaks something
I have running on my machine, Norton AntiVirus, McAfee AnitVirus, McAfee Firewall, and Zone Alarm. (I am not paranoid.) I recently installed Visual Studio. And when I tried to create a new project I got presented with a can not load class error. After searching on Google I discovered that both McAfee and Norton AntiVirus try to register their own version of Scripting.FilesystemObject. In the posting that I read, it told me to go to the registry and change the file back to the Microsoft one. That fixed the problem, however my system is now less secure because my Virus software is not managing scripts that use the FilesystemObject. Security is a great thing until it causes problems. The most secure computer is the one that is turned off. However, this doesn’t help me.
Monday, March 29, 2004
Computers Suck
Well, I don’t know if I agree that computers suck. However, I do think that technology is only just beginning. What we will create tomorrow will be better, cheaper, reliable, and far more useful.
Sunday, March 28, 2004
Building Better Applications
I see a lot of good ideas and a lot of software that could be written better. In most cases the software that I like and would actually pay money for are the applications that integrate well with windows or other commonly used applications. I use NewsGator not because there is a lack of free blog aggregators, but because NewsGator is easier to use. It adds a popup menu in IE so that I can easily subscript to new blogs. It is an Outlook plug-in so I don’t have to learn a new tool. It also has a website to check my blogs when I am away from my computer. It integrates well into the tools that I use everyday. This is what separates good software from great software.
Good job NewsGator.
Good job NewsGator.
Thursday, March 25, 2004
Why is code maintenance so difficult?
The more complicated your code base is the less likely other people will be able to understand it. So how do you make it simpler? Well, there is no easy answer to this, even when you try to write understandable code different people with different ideas may find it incomprehensible. That said here are some things to think about when writing code.
Stay away from form inheritance. Languages like Delphi have the concept of form inheritance (creating a base window and then inheriting off it). Although this can be great in the initial creation of applications, allowing you to create many forms quickly, it is hard to maintain. What if there is a button that is no longer needed, and that button lives on the base form. You can not delete the button because that would delete it on every descendant form. So you end up hiding it. Now you have controls that in design time clutter your designing window. The problem gets worse when you need to radically change your window’s visual appearance. Now what do you do? Hide more controls or start over? Well in this case the two options are not ideal. You will end up with more confusing un-maintainable code or you will waist time rewriting the window. I think rewriting it to the way to go. Rewrite it to the way it should have been in the first place, with out inheritance.
Try not to inherit more then three levels deep. Unless your objects are created perfectly and no one will need to maintain it, inheritance is not your friend. When it comes time to extend functionality it becomes very confusing to figure out where the code belongs. Does it belong in the base or at what level? Fixing bugs can also be difficult; trying to follow the call stack as it jumps from one level to the next can be tricky. There are times that each level is very straight forward however most times the lines get blurred and functionality ends up existing at levels it shouldn’t.
Minimize the amount of code files. If you have inherited objects that exist in multiple files think about putting them into one file. If someone need to make changes it is easier because everything is in one place. Organization can go a long way. Another solution is to create a directory that holds common files.
Try not to wrap objects for the sake of making things simpler. Of course there are times that you need to wrap DLL’s or COM objects. However, if you are trying to create easier access to code by writing more code this is probably not a good thing. The less code the better. Unless you have a really good reason to do it, don’t do it.
If you have a frame-work, document it well or better yet buy one. If in your project you try to make thinks easier by writing a frame-work that you can just plug-in objects, this may seem like a good idea, just make sure that you document it well. Everyone must understand it and be able to maintain it. If you can buy a framework you are probably better off. Developers are more likely to adopt a third-party solution then one created in house.
Diagram your software. A picture is worth a thousand words and a code picture is worth a thousand lines of code. Diagrams can make things easier to understand they can show relationships very well, and can go along way in helping others to understand what your code does.
Try to teach others your coding ideas. If no one understands what you are trying to do then know one will be able to maintain your code. Also in the process of documenting or teaching others you may find code that could have been written better. This is a great opportunity to make your code more understandable.
Stay away from form inheritance. Languages like Delphi have the concept of form inheritance (creating a base window and then inheriting off it). Although this can be great in the initial creation of applications, allowing you to create many forms quickly, it is hard to maintain. What if there is a button that is no longer needed, and that button lives on the base form. You can not delete the button because that would delete it on every descendant form. So you end up hiding it. Now you have controls that in design time clutter your designing window. The problem gets worse when you need to radically change your window’s visual appearance. Now what do you do? Hide more controls or start over? Well in this case the two options are not ideal. You will end up with more confusing un-maintainable code or you will waist time rewriting the window. I think rewriting it to the way to go. Rewrite it to the way it should have been in the first place, with out inheritance.
Try not to inherit more then three levels deep. Unless your objects are created perfectly and no one will need to maintain it, inheritance is not your friend. When it comes time to extend functionality it becomes very confusing to figure out where the code belongs. Does it belong in the base or at what level? Fixing bugs can also be difficult; trying to follow the call stack as it jumps from one level to the next can be tricky. There are times that each level is very straight forward however most times the lines get blurred and functionality ends up existing at levels it shouldn’t.
Minimize the amount of code files. If you have inherited objects that exist in multiple files think about putting them into one file. If someone need to make changes it is easier because everything is in one place. Organization can go a long way. Another solution is to create a directory that holds common files.
Try not to wrap objects for the sake of making things simpler. Of course there are times that you need to wrap DLL’s or COM objects. However, if you are trying to create easier access to code by writing more code this is probably not a good thing. The less code the better. Unless you have a really good reason to do it, don’t do it.
If you have a frame-work, document it well or better yet buy one. If in your project you try to make thinks easier by writing a frame-work that you can just plug-in objects, this may seem like a good idea, just make sure that you document it well. Everyone must understand it and be able to maintain it. If you can buy a framework you are probably better off. Developers are more likely to adopt a third-party solution then one created in house.
Diagram your software. A picture is worth a thousand words and a code picture is worth a thousand lines of code. Diagrams can make things easier to understand they can show relationships very well, and can go along way in helping others to understand what your code does.
Try to teach others your coding ideas. If no one understands what you are trying to do then know one will be able to maintain your code. Also in the process of documenting or teaching others you may find code that could have been written better. This is a great opportunity to make your code more understandable.
Top Down VS. Bottom Up
There are two approaches when it comes to designing software, top down approach and the bottom up approach. The top down approach is when the developer is given a list of requirements and thinks about how the UI will look and how the user will use the UI. The developer will then just start writing code. With RAD development tools like Delphi, VB, etc it is very easy to create a window, start dropping controls on it and start writing code to respond to buttons, menu items, etc. The bottom up approach is when the developer gets a list of requirements and starts thinking about what objects are required to perform the tasks. Thought must be given to what the UI will do and how the UI will interact with the objects, but the UI is only a means to communicate with the core objects. After the initial design the developer will start coding the implementation of the objects and then build the UI to communicate with the objects.
The top down approach is faster. Most prototypes and simple applications are written this way. You can develop it quickly, get feed back and get it to market in a relatively short amount of time. And if the code is not very complicated it is easy to maintain. The problem is when things become more complicated. As time goes on and requirements grow and the amount of code written reaches a level that makes the code difficult to comprehend, maintenance becomes difficult. And if you are working in a team environment probably only the initial developer will be able to maintain the code in a decent manner. Also bug can start appearing because of the complexity of code. Because decisions are based on how the user uses the UI chances are that not all users will agree, some users will want to do things one way while others will want to do things another. This leads to switches and settings in your code that over time can result in spaghetti code, because things are not thought out the end result is very difficult to maintain and error prone. There is also the problem of adopting newer technologies. Because the code base is all tied together chances are that any changes to components will be significant, you will probably have to test everything before you redeploy because you may not know what the impact of the change will be.
The bottom up approach may be slower at the start but more maintainable in the long run. You have to think about what you are doing. If you happen to be wrong you run the risk of wasting valuable time. You also must be careful not to over think things. However, your code will be more maintainable. If you create UML diagrams, this can act as a blue print of your software. Much like database administrators use ERDs (Entity Relationship Diagrams) to view their relationships in their databases, a UML class diagram can show the object relationships of your software. UML can also be used to show the flows of messages through different objects or give a high level overview of how the different sections relate to one another. Further more, as new requirements come in developers are forced to think about how this will affect the core application. Most of the bugs that I see are caused because developers are not thorough when adding new functionality. There are also many benefits to having your UI separate from your object model.
- You can build test scripts to test your object model. This can test the core functionality of your application. Although it can not test everything it can catch some bugs early on and help the developer maintain a reliable code base.
- You can migrate your code. Because you have a separation of UI and objects you have a place to start migrating code. If the UI must change you know that this will not impact the core. Perhaps you are trying to move your application to the web, or perhaps you would like a fancier UI. Furthermore if you would like to move your application to Linux or .NET moving the objects first is easier. Most portability problems are in the UI controls. You may have to rewrite parts of the UI but this is far better then having to rewrite your business logic.
- You can turn your object model into a stand alone API. Perhaps some users would like the ability to create their own UI or may want to integrate your functionality into one of there own applications. This can make your code more valuable and more useful.
I would suggest only using the top down approach in cases when you want to get your software to market quickly and don’t care about long term maintenance. For more serious projects I would suggest the bottom up approach. It may require more time up front however the time saved in maintenance will be well worth the effort.
The top down approach is faster. Most prototypes and simple applications are written this way. You can develop it quickly, get feed back and get it to market in a relatively short amount of time. And if the code is not very complicated it is easy to maintain. The problem is when things become more complicated. As time goes on and requirements grow and the amount of code written reaches a level that makes the code difficult to comprehend, maintenance becomes difficult. And if you are working in a team environment probably only the initial developer will be able to maintain the code in a decent manner. Also bug can start appearing because of the complexity of code. Because decisions are based on how the user uses the UI chances are that not all users will agree, some users will want to do things one way while others will want to do things another. This leads to switches and settings in your code that over time can result in spaghetti code, because things are not thought out the end result is very difficult to maintain and error prone. There is also the problem of adopting newer technologies. Because the code base is all tied together chances are that any changes to components will be significant, you will probably have to test everything before you redeploy because you may not know what the impact of the change will be.
The bottom up approach may be slower at the start but more maintainable in the long run. You have to think about what you are doing. If you happen to be wrong you run the risk of wasting valuable time. You also must be careful not to over think things. However, your code will be more maintainable. If you create UML diagrams, this can act as a blue print of your software. Much like database administrators use ERDs (Entity Relationship Diagrams) to view their relationships in their databases, a UML class diagram can show the object relationships of your software. UML can also be used to show the flows of messages through different objects or give a high level overview of how the different sections relate to one another. Further more, as new requirements come in developers are forced to think about how this will affect the core application. Most of the bugs that I see are caused because developers are not thorough when adding new functionality. There are also many benefits to having your UI separate from your object model.
- You can build test scripts to test your object model. This can test the core functionality of your application. Although it can not test everything it can catch some bugs early on and help the developer maintain a reliable code base.
- You can migrate your code. Because you have a separation of UI and objects you have a place to start migrating code. If the UI must change you know that this will not impact the core. Perhaps you are trying to move your application to the web, or perhaps you would like a fancier UI. Furthermore if you would like to move your application to Linux or .NET moving the objects first is easier. Most portability problems are in the UI controls. You may have to rewrite parts of the UI but this is far better then having to rewrite your business logic.
- You can turn your object model into a stand alone API. Perhaps some users would like the ability to create their own UI or may want to integrate your functionality into one of there own applications. This can make your code more valuable and more useful.
I would suggest only using the top down approach in cases when you want to get your software to market quickly and don’t care about long term maintenance. For more serious projects I would suggest the bottom up approach. It may require more time up front however the time saved in maintenance will be well worth the effort.
Why is TDD so boring?
This is an interesting read on Test Driven Development (TDD).
http://www.ftponline.com/weblogger/forum.aspx?id=9&Date=3/22/2004
http://www.ftponline.com/weblogger/forum.aspx?id=9&Date=3/22/2004
Subscribe to:
Posts (Atom)