Tag: tools

  • The Value Of Re-inventing The Wheel

    The Value Of Re-inventing The Wheel

    A prior post discussed some of the challenges with using code generators.  One thing we did not cover was the value of re-inventing the wheel.  In particular, this holds true when we are learning problem-solving.  That means one of the ways to become better developers is to solve problems that have already been solved.  The objective is not so much the solution as the process.

    Skipping Ahead Without Re-inventing The Wheel

    Software developers often use frameworks and code generators to improve productivity.  They also can find ways to quickly code a series of common modules through libraries and pre-built scripts.  That approach is obviously a route to rapid development.  However, it also is a potential way to allow skills to rust from lack of use.  We can say we do not need to re-invent the wheel, there is no value in solving something where the solution is known.  However, that is not completely true.  There is value in analyzing a problem and finding a solution even when it is known.  We learn how to think in a critical and logical manner.  There are also repeated patterns in developing solutions.

    Repetition Across Solutions

    The idea of patterns emerging in problem-solving is not often discussed.  They tend to be a sort of obvious secret or maybe even common sense.  Nevertheless, we need to be able to apply these patterns to become better problem solvers.  The stories about Sherlock Holmes show some of these.  Sometimes it is all a matter of deduction, or maybe a process of elimination.  There are these sorts of solution patterns that can be used over and over in solving even very complex problems.  The more we are familiar with these patterns, the more we can combine them into new and complex solutions.  When we skip to the solution on common problems, as we do with code generators, we also pass on that learning opportunity.

    I think that persistence is often undervalued. That is another skill we do not develop when we take the shortest path to a solution. There is value in spending time banging one’s head against a problem while we try to solve it. We also can develop good habits as we struggle through those “simpler” problems. Think of code generators and frameworks as a way of pushing the cost of developing skills down the road. There are times that is needed. However, we may end up paying an exorbitant price in the future. That is not much different from pushing upgrades off to the future and eventually paying a huge price or even being blocked from an upgrade path.

    The Power of Persistence

    One of the traits of a strong developer is persistence.  We encounter all manner of obstacles that require us to persevere as developers.  These are well-known among us and range from simple headaches like a hard-to-find misspelling to magic numbers and complex configuration combinations.  Re-inventing the wheel can be a path to practice such patience and perseverance.  The benefit of these well-known problems is that we have ways to move us forward when we are blocked.  We get to go through the motions with a form of training wheels to help us get past steps that stop our progress.

    These are areas where practice helps us.  Thus, using tools that help us skip ahead on problems can remove that practice and the related benefits.  A similar example is a basketball player that skips free throws because they know they can make them.  We also have mental “muscles” that can be exercised to create muscle memory and better performance in other areas of problem-solving.

  • Reasons To Avoid Code Generators

    Reasons To Avoid Code Generators

    When one goes looking for reasons to use code generators, the articles tend to skew positive. I guess most people need to be convinced that these are good tools. However, there is a dark side to code generators. Well, that may be a bit over-dramatic. However, there are reasons that a code generator should be avoided and definite drawbacks to using one. Allow me to make the case against these productivity tools.

    Ignorance By Abstraction

    The first problem we can look at is what I call ignorance by abstraction. This effect happens when we shield people from the underlying process for any task. For example, you look at your watch and read the time. You have no idea how it “knows” what time it is. You are ignorant of that functionality or process. Code generators often provide that abstraction. Yes, a developer can always review the source code. However, how often do you see that happening? There may be an initial deep dive into the generated code when the tool is evaluated. That is where it ends in most cases. You assess the tool and then trust it. Future developers may blindly use it and never even see the source code.

    Confusing Custom With Standard

    Frameworks also suffer from this weakness, but code generators hide it better. This situation occurs when a developer gets so used to how a tool helps, they think it is part of the environment. There are many developer tools that fall into this category. The result can be great for productivity but can also end with tool lock-in or limit career moves. I have come across developers that end up stuck in a job because they are so reliant on the tools that the company provides. That may seem like a win for the company, but it can scare away better talent. These environments also deter those that want to focus on learning a language or environment. Instead, your team is just learning tool usage.

    Performance And Maintenance Woes

    An often overlooked weakness in code generators (and frameworks) is how they provide a general solution. In some cases, this just leads to unused code. On the other hand, it can lead to slow code that is difficult to maintain. It can be frustrating and time-consuming to sort through excess code while debugging. There also are performance issues that often arise. The best way to build a code generator that allows for extensible code is through abstraction. However, those abstraction layers take time to process during runtime. That can cause performance issues that cannot be overcome. The generated code provides a baseline that cannot be moved without removing the tool. When you hit those sorts of walls, you will hear a lot of wailing and gnashing of teeth.

    Regeneration Nightmares

    I worked on code generators early in my career for a tool called Power Builder. We ended up often having more layers on top of the primary tool than it supported. We ended up spending hours each week in generation and regeneration and compiling cycles. I lost track of how many hours were spent in non-productive waiting for a system process to complete. This was not uncommon in those days of application compiles that often took dozens of minutes or more. Nevertheless, we had to be aware of what might be over-written in our code during a regeneration process. Likewise, there are side effects we might have on the same. I am not sure the resulting time savings were worth it.

    Scalability and Extension

    That leads to another weakness code generators can run into. They do not always scale. I have run into this often with RDBMS object mapping generators. The tools have an approach that makes assumptions that make sense until you get to large or complex solutions. The problems may occur as name collisions, objects with too many properties, tables with too many columns, or overhead that buries the system. Consider what audit information adds when you scale it to large and complex systems. Do you really need audit information for every data lookup item?

    While some solutions and generators provide configuration or customization, that can also be expensive in both time and performance. There is a chance that an update of the tool or even a new code generation will break custom code. Those changes may also fall outside of the patterns the code generator uses and have a negative impact on application performance. Think of it as the tool plotting a specific course through the generated code. Then, the customization tries to change the course. There is a form of working against yourself that occurs in those situations that can cause maintenance and performance degradation.

  • Ask And You Can Find The Tool

    Ask And You Can Find The Tool

    A recent discussion with an associate reminded me how often we ignore some great solutions for our problems. The Internet provides us with an easy way to evaluate literally dozens of options for many of our common problems. It is worth the investment to find the tool that suits our needs. Even better, we can learn that our problems are more common than we think. Even a niche problem will often have a number of potential solutions a good search away. While we can all stumble around and find some great gems, sometimes a plan is helpful.

    Avoid Distractions

    Apple showed that less can be more. Likewise, there is a lot of research related to having a large number of options. That makes sense. We can all relate to analysis paralysis, but it does occasionally sneak up anyway. A problem we want to be solved seems to make us even more susceptible to this problem. It creates a sort of “kind in a candy store” situation. We focus on a problem, find some solutions and suddenly we can be almost giddy. If you doubt it, then take a look at search results for any passion of yours. Maybe check out some new cars, beach homes, or enticing coffee flavors. When we get what we want we are more than happy to enjoy the shopping experience and getting lost in what-ifs. The Internet provides us too many options so we need to reduce that list quickly.

    Have A Plan

    One of the essential reasons for an RFP is to define what an organization needs. We see this in problem-solving all the time. A well-defined problem is easier to solve than one that is vague. Take similar steps to start your search to find the tool desired. Think about what you want and create a list of priority features along with some nice-to-haves. You can do this in a matter of minutes, and it does not need to be complete. Start your search focused on solutions that provide the requirements you listed. It is not uncommon to learn about features that most providers include or new options you did not know you required. Feel free to adjust your list as needed.

    Be Heartless In Reducing Options

    The final goal is to get your list to five options or less. That five number is on the outside. Most lists should be down to three at this point, if possible. That may seem like a difficult task. However, I have found in most situations you can find the products available and reduce the scope of “viable options” to a few within a few days at most. Also, it only takes days when there are dozens of options and they are complex solutions. Most applications whether a task tracking solution, an e-commerce platform, or a coding utility, can be swept through in a matter of hours. You can often find what you need to know with surface reviews and related searches. They will either meet your requirements or not. Price alone can often reduce your list quickly.

    Due Diligence

    The final step is to evaluate your shortlist of options. This step is time-consuming and essential in making the best decision. It often includes installing a trial version or using a demo period to get to see the solution in action. You might even watch vendor presentations and spend time discussing how a solution is the best for your needs. The process may seem like something that requires too much time. Nevertheless, spending time to find the tool or effective solution can often save you hours, days, or even months in the long run.