TDD : DO I reallly needs to learn it ?
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
Depends on your definition of 'learn'. I would suggest that you do as Marc Clifton did. Implement something using the methodology so that you become sufficiently familiar with it that you are able to make a reasoned judgement on whether it is suitable for projects/jobs that you are tasked with. Of course, if it is not suitable then you could always try The Glacial Methodology[^]. :)
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
Do you think Picasso made TD works? Even if you aren't such an artist, but feel yourself like a good little software artisan (or at least you have such an illusion) then TDD may be more pain than advantage. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
First, lets make a distinction between xUnit testing frameworks and Test-Driven Development (TDD). xUnit Test Framworks act as a "code-vice" to hold your code in a fixed stable position while you make changes. The driver that manages when the tests are run etc is built into the the framework. The only thing that is left to the developer is to write individual tests to verify functionality. Test Driven Development often uses an xUnit framework, and is a methodology where you write the tests first, watch the test fail calling the unimplemented function. Then the actual code is developed to pass the tests. At first you may simply make the simplest implementation possible. But as more scenarios are determined, more tests are created, and you refactor your implementation. Each time knowing if you last change was a good change, or a bad change. Keep in mind, both of these work best on discrete units of code. Each test suite would verify one class, or algorithm. Trying to test an entire application is not focused enough to be beneficial. I discovered it 3 years ago, and use it for both my work and hobby code. I don't end up writing unit-tests for everything that I write, however, I still develop the tests for the majority of my code. I can't say whether you are missing out on something or not. Every programmer has their own favorite tools, processes, and junk-food to program with. I still run into programmers that prefer trouble-shooting problems using printf rather than the debugger. What I can tell you are the benefits I have experienced, then a few of the inconveniences. 1) I get to use my object interfaces before I have completed their implementation. This has saved me a ton of time when I think I have a good interface defined, only to find out it is too cumbersome, or even unusable when I go to write the tests. At this phase, I actually get to write the code how I would like to use my objects. 2) It is quite often true that I end up with more unit-test code than actual production code. However, I also have less production code than I would have written without the tests driving my development. Why? I quit over-analyzing my objects thinking, "oh, it would be really cool if I added ...". When I write my tests, I write for the functionality that I need, and no more. If I need that cool feature later, I can add it later. 3) I have learned how to write unit-testable production code. It's part of the methodology, you design your objects to be testable. When you imp
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
Like yourself I'm also a self taught programmer. I just learned TDD and applied in my current projects, I can say it really makes the development process easier and helps you deliver a much more robust product. In my opinion, its something you should consider learning.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
When I first heard about TDD I couldn't figure out how it was different than what I was doing already ... write a bit, test, write a bit more, test. TDD allow me to formalize what I was already doing by making it easier to write the unit tests I had to write anyway, and these represented a way of passing the torch on to the next person who had to maintain what I wrote, because it documents your assumptions that another developer can easily read. Proof of TDD came on a project where I had to write a complicated calculation engine consisting of perhaps 15,000 lines of code and tens of thousands of inputs. The system was delivered with just two bugs, and both bugs were because of specifications they never told me about. I'm pretty thorough as it is with my software, and have few bugs in general but to know precisely there were only two bugs made me pretty proud. If you are working with others and have to hand off your code, TDD is the way to go. If you have to write unit tests for your code, then TDD is definitely the way to go. Unit test writing after you've written the code is as dull as watching paint dry. But I found that writing tests as you developed didn't feel like writing test cases at all. To know you haven't introduced bugs into your code is also a big benefit. There is a certain kind of pleasure to see all your tests continue to pass green each time you run them too. As to whether you want to learn it or not is really up to you. But if you have to hand off code, or you write code that is very complicated, I think you're foolish not to use TDD. My two cents.
-
Yes, you are definitely missing something. The 4000 users number isn't very indicative of when to use TDD. But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features because your users don't want to wait 3 years until all of them are finished. In that case you need some automated testing.
Wout
wout de zeeuw wrote:
But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features
It would be fascinating to read something that would explain how TDD would uniquely contribute to, or be essential to, the solution scenario you describe above ... compared with other so-called "development methodologies." best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
-
Not from the guys that advocate TDD. Unless... well, no. A totally unrelated thing, did you ever realize how nice our society is to complete crackpot nutjobs as long as they don't actually drool? Baaack to the topic: it is worthwhile to write unit tests as an exercise (i.e. repeat often, on different topics). This not only teaches you to write them (always good to have some around) but also what code lends itself well to them. if you feel confident, try writing them before the code and see for yourself.
The problem with the TDD crowd is that they are so enamored with it that they now consider it a test driven design. That's right, by writing your tests first, you will end up with a good design.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchypeterchen wrote:
A totally unrelated thing, did you ever realize how nice our society is to complete crackpot nutjobs as long as they don't actually drool?
No. best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
-
When I first heard about TDD I couldn't figure out how it was different than what I was doing already ... write a bit, test, write a bit more, test. TDD allow me to formalize what I was already doing by making it easier to write the unit tests I had to write anyway, and these represented a way of passing the torch on to the next person who had to maintain what I wrote, because it documents your assumptions that another developer can easily read. Proof of TDD came on a project where I had to write a complicated calculation engine consisting of perhaps 15,000 lines of code and tens of thousands of inputs. The system was delivered with just two bugs, and both bugs were because of specifications they never told me about. I'm pretty thorough as it is with my software, and have few bugs in general but to know precisely there were only two bugs made me pretty proud. If you are working with others and have to hand off your code, TDD is the way to go. If you have to write unit tests for your code, then TDD is definitely the way to go. Unit test writing after you've written the code is as dull as watching paint dry. But I found that writing tests as you developed didn't feel like writing test cases at all. To know you haven't introduced bugs into your code is also a big benefit. There is a certain kind of pleasure to see all your tests continue to pass green each time you run them too. As to whether you want to learn it or not is really up to you. But if you have to hand off code, or you write code that is very complicated, I think you're foolish not to use TDD. My two cents.
+5 Of all the replies to this thread, this seemed the most specific, the most reasonable, the most eloquent, the most practical ... to me. thanks, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
-
Do you think Picasso made TD works? Even if you aren't such an artist, but feel yourself like a good little software artisan (or at least you have such an illusion) then TDD may be more pain than advantage. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Actually, to some extent, yes, I think artists in general do use some kind of test system and 'agile development process': they sketch their idea on a slip of paper, then on the canvas, maybe discuss it with others, and focus to fix the idea of what their work should express in their mind. They usually don't care all that much how every shade on the image looks, but how it contributes to the overall expresssion of the work. They may not actually write test cases, but they do work to a very specific goal in their mind. It may be less obvious when you look at the more extravagant artists and how they work. but I'm convinced that they, too, have a very clear idea in their mind of what they're about to create when they work, even though to others it may not appear so. And they do, regularly, pause to check whether their creation so far is on the right way to what they had in mind. You could consider that some kind of testing.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
I used to think that one-person projects are small enough to get away without the effort of extensive test frameworks and similar advanced measures of QA. And the projects I've worked on appeared to confirm my beliefs. But when I started setting up a unit test framework for a small library in an attempt to introduce testing for a larger app, I realized - even before implementing the tests, just how much more I started considering about the inner workings and special cases. In other words, just thinking about what to test made me realize a number of things I otherwise wouldn't have until much later. Or at all. Thinking about each individual test and how to guarantee the preconditions for each, forced me to think through the whole collaboration both within the library, and with other parts of the application. Once I had all the test cases covered, I knew my library classes would have all necessary functions (at least the public ones). If I had gone about it without concern for testing, I would have forgotten a lot of functions and would have to add them later. TDD also made me realize that a few functions that I thought I'd need and added to the class interface, weren't needed after all. Finally, the realization of what was really needed, and what not, helped me make a couple of very important design decisions, before creating the classes, e. g. where to use inheritance, templates, or neither, or that a particular class actually wasn't needed. So to conclude: You may not need TDD for small projects (or even moderate large ones), but using it will influence your design decisions and could give you a better understanding very early in the development process. I do believe that TDD will give you a better design. What I can't tell you though, is under which circumstances the additional effort is actually worth it. Often the second best design is good enough. I guess you could tell better by experience - so it probably would help you to get some. :)
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
What is TTD actually? I never heard of it..
-
wout de zeeuw wrote:
But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features
It would be fascinating to read something that would explain how TDD would uniquely contribute to, or be essential to, the solution scenario you describe above ... compared with other so-called "development methodologies." best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
Mostly I try to stay away from projects that are large and formal, because it doesn't quite fit the way I like to do things. I like projects where I do little testing and the environment is small enough so I can release a patch within a couple of minutes. But in case you're sending a rocket up to space, you'd better have some evidence that you tested the code. Also in health care often you need to keep records of your software tests, so guys from the FDA can come in and audit your software process. In some cases you can even prove mathematically something works, but I have never seen that being applied in the real world.
Wout
-
I used to think that one-person projects are small enough to get away without the effort of extensive test frameworks and similar advanced measures of QA. And the projects I've worked on appeared to confirm my beliefs. But when I started setting up a unit test framework for a small library in an attempt to introduce testing for a larger app, I realized - even before implementing the tests, just how much more I started considering about the inner workings and special cases. In other words, just thinking about what to test made me realize a number of things I otherwise wouldn't have until much later. Or at all. Thinking about each individual test and how to guarantee the preconditions for each, forced me to think through the whole collaboration both within the library, and with other parts of the application. Once I had all the test cases covered, I knew my library classes would have all necessary functions (at least the public ones). If I had gone about it without concern for testing, I would have forgotten a lot of functions and would have to add them later. TDD also made me realize that a few functions that I thought I'd need and added to the class interface, weren't needed after all. Finally, the realization of what was really needed, and what not, helped me make a couple of very important design decisions, before creating the classes, e. g. where to use inheritance, templates, or neither, or that a particular class actually wasn't needed. So to conclude: You may not need TDD for small projects (or even moderate large ones), but using it will influence your design decisions and could give you a better understanding very early in the development process. I do believe that TDD will give you a better design. What I can't tell you though, is under which circumstances the additional effort is actually worth it. Often the second best design is good enough. I guess you could tell better by experience - so it probably would help you to get some. :)
excuse my ignorance but do you apply TDD to data as well? do lets say I have a depreciation class that does financial depreciation by loading up some data and calling a stored procedure. How would you use TDD in this scenario ? Do you have to set up your data before every test and then check that the correct depreciation entries were made in the database? We have heard that TDD is not really useful in UI, I guess what I'm asking is how well does TDD work with checking: a) the source of the data b) the processing of the data c) the resulting data. So many of our apps nowdays are heavily dependant on databases does TDD suit this scenario?
-
excuse my ignorance but do you apply TDD to data as well? do lets say I have a depreciation class that does financial depreciation by loading up some data and calling a stored procedure. How would you use TDD in this scenario ? Do you have to set up your data before every test and then check that the correct depreciation entries were made in the database? We have heard that TDD is not really useful in UI, I guess what I'm asking is how well does TDD work with checking: a) the source of the data b) the processing of the data c) the resulting data. So many of our apps nowdays are heavily dependant on databases does TDD suit this scenario?
I don't consider data to be separate from the program with respect to testing! A program can fail both of incorrect implementation or from bad data, but in the latter case, there should be a specified error behaviour, and a test case covering it. That means that a single function shouldn't be covered by just one test case, but several ones that verify the expected behaviour for both good and bad cases. Each test case therefore does include specific data. I realize that just setting up such test data sets could be very difficult in some cases - it sure is in our application and I've yet to find a good method. With respect to databases I'd like to add that articles on testing like to mention the option to replace complex parts of your system (such as databases) with mock objects: e. g. instead of connecting to an actual database, you create an object that implements the same interface, but all it does is just deliver the data you require for a specific test. Of course that implies that you *have* an interface to start with, and a factory pattern to create the real object - else you would need to change the code that accesses it, i. e. the code you're supposed to test, and that would be beside the point.
-
I used a small project a few years ago to try out TDD. Pros: * I learned a lot about writing useful unit tests, not just the "does it handle a bad argument in the method" garbage most unit tests seem to do. * It got me thinking about architecture much earlier * It got me thinking about functionality and it was neat to have stubs for various classes and methods, and as the stubs got filled in with actual code, watching the little red lights turn green. * I enjoyed thinking about things from a different perspective. Cons: * There's a disconnect between developing the test, no matter how well you think you've designed the architecture, and actually implementation when you realize you need to tweak the architecture. * The tests became a liability--they frequently needed updating as the architecture changed * As coders, we think we can test code. But most of what I ended up needing tests for was UI behavior. What's the best way to make sure a method doesn't get called? To disable the button or combobox so the user doesn't do something prematurely! Writing test code for UI's is not the same thing as writing tests against code. Big fail in the TDD concept, in my opinion. * Effectively doubles the time it takes to put out a project. No, it doesn't save time. No, it doesn't necessarily make the code more robust. You can easily end up with more test code than actual application code. * Set up for complex projects is, well, complex. Setting up initial data, etc. * Without a mocking framework, TDD is sort of useless for anything but trivial tests. You need a mocking framework to spoof the DB connection, the communication channels, the UI, etc. So, ultimately, I came to the conclusion that it's a nice idea, it's a useful tool, but use it judiciously. Like anything else! Marc
My Blog
An Agile walk on the wild side with Relationship Oriented ProgrammingAs someone who started trying TDD last Feb but really hit it hard on a project a few months ago, here's my takeaway regarding some of the cons. UI testing is getting more and less of a problem. Frameworks like MVC are making it so that if things are written well there should be very little view logic in your controller code. I'm incredibly grateful to no longer have to see code like (if data = 37 then control.hide()) or something similar. On the other hand, so much logic is happening in Javascript now that unless you're using something like QUnit (and enforcing it among the teams) you're back to square one. I'd argue TDD does save time, but that time is manifested as time you didn't have to spend researching, finding, fixing, testing, and deploying a bug. We've just started TDD on a project and I've seen what happens when tests are run and I've seen the case where we've chased a bug only to be frustrated that had the developer who changed the feature run the tests (or if the automation had run it...different problem heh) we'd have saved a few hours. TDD certainly increases your dev time though, no question there. Speaking from a .NET perspective, with things like RhinoMocks and Moq, not having a mocking framework really shouldn't be an excuse. And if you're doing IoC you have Ninject, StructureMap, etc., so building apps in such a way that you can use a mocked db layer or a real one should also be fairly simple. My two cents.
-
I don't consider data to be separate from the program with respect to testing! A program can fail both of incorrect implementation or from bad data, but in the latter case, there should be a specified error behaviour, and a test case covering it. That means that a single function shouldn't be covered by just one test case, but several ones that verify the expected behaviour for both good and bad cases. Each test case therefore does include specific data. I realize that just setting up such test data sets could be very difficult in some cases - it sure is in our application and I've yet to find a good method. With respect to databases I'd like to add that articles on testing like to mention the option to replace complex parts of your system (such as databases) with mock objects: e. g. instead of connecting to an actual database, you create an object that implements the same interface, but all it does is just deliver the data you require for a specific test. Of course that implies that you *have* an interface to start with, and a factory pattern to create the real object - else you would need to change the code that accesses it, i. e. the code you're supposed to test, and that would be beside the point.
Your reply makes sense, I find that most of our code "fails" because it encounters some data that is incorrectly configured and it then behaves in a way that the user is not expecting. The data was incorrectly configured by the user. To test multiple scenarios of configurations you would need to have multiple databases, alternatively, write a test script that prepares data then tests against that data. It all seems like an inordinate amount of work, do people really do this? I suppose thats why for the past 20 years we have let our users do the testing!
-
Your reply makes sense, I find that most of our code "fails" because it encounters some data that is incorrectly configured and it then behaves in a way that the user is not expecting. The data was incorrectly configured by the user. To test multiple scenarios of configurations you would need to have multiple databases, alternatively, write a test script that prepares data then tests against that data. It all seems like an inordinate amount of work, do people really do this? I suppose thats why for the past 20 years we have let our users do the testing!
Technically, yes, you'd have to provide test cases for everything that could go wrong, and that would indeed cost a lot of effort. A compromise would be to just provide one or a few cases of bad data, and only add more cases when you actually encounter a specific case that wasn't covered. It would prevent you from creating dozens of bad cases that in praxis never reeally happens. You'd still be able to run regression tests that way, i. e. when you fix a new bug, by always adding a test case for it you can make sure that the tests for already fixed bugs still pass. In the end it's you who must weigh the benefits of testing more against the effort it takes to produce these tests.
-
What is TTD actually? I never heard of it..
The general software design process looks roughly like this: 1. gather requirements 2. write use cases 3. implement them 4. write tests 5. test against the requirements In TDD it's more like 1. gather requirements 2. write test cases 3. implement them 4. write use cases 5. implement those 5.a) continually test the use case implementation using the already implemented tests Technically it shouldn't be all that different, but in praxis, tests are often written by the developers and tend to cover only the functionality that they have implemented, rather than the requirements that are supposed to be met. That only works if the use cases really fully cover the requirements, and the implementation really fully covers the use cases - and both are sometimes hard to verify. In TDD the test are written beforehand, the only information you can base them on are the requirements, so you're forced to implement that. Even if you lose information while writing and then implementing use cases, you'll catch that in testing. At least that is my understanding - you may want to check out wikipedia or other sources for a more in-depth explanation.
-
wout de zeeuw wrote:
But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features
It would be fascinating to read something that would explain how TDD would uniquely contribute to, or be essential to, the solution scenario you describe above ... compared with other so-called "development methodologies." best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
Wout hit it right on the head, IMHO. TDD's major value is in reduced cost of maintainability. If it's a ship it and forget it project, I've not found the overhead to be worthwhile. Conversely, if you are dealing with code you'll be enhancing, tweaking, and growing over months and years, the efficiency gains in pinpointing problematic code rapidly outweighs the overhead of writing the code.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
I recall someone on gamedev once stated he finds books unnecessary as he taught all(!) software solutions to himself without any help. You might agree that this is likely a limited view angle. Trying new things is rarely the fastest way forward in my experience, but it might give you new valuable perspectives, even on things you already knew.