Writing your own framework or using an existing one?

Question

I know there are similar questions to this one, and I've read most of them. Most of the answers to these questions are talking about "cost-effectiveness" and "time-saving" aspects of the frameworks, which are huge reasons in favor of using frameworks.

I'm a pretty new .NET developer and I'm trying to learn stuff like WPF, MVVM, layered architecture design, dependency injection, logging, database access, test-driven development, and many more different technologies/techniques.

Most of the resources that I find regarding such topics start with an extremely simple example to "show" why you should use given technology/technique, which honestly looks quite ok with that simple example, but doesn't really make sense for someone who didn't deal with real-world problems these technologies/techniques help with.

After the simple example that makes me wonder what that specific technology/technique really solves, they usually go on and say "Hey, you know what, there's a framework for that called ..., let's just use it for the rest of the examples." Dependency injection? Just use Ninject. You want to fake stuff? C'mon just use Moq. MVVM? You're kidding me? just use MVVM Light Toolkit!

Which is great, really. All these tools, I'm sure, make the life easier for all the developers out there. But my problem is,

1. I'm trying to use TDD, but I have never experienced the problems people experienced while they were developing stuff without TDD, which in the end made them come up with such a technique. I understand the concept behind, theoretically I can see why it was created, but in practice I am not experienced enough to see a code that would benefit from TDD. Because I haven't seen much.
2. I have never had problems developing a huge application that I needed to de-couple stuff and went "Oh my god! That is ridiculous! I need to find a technique so that I won't have this much trouble next time." and found out about "Dependency Injection". All the small things that I have developed so far worked fine without the need of dependency injection.
3. I have never written a WPF application that made me feel like things should be easier, presentation layer should be separate, there should be data binding. Hell, I haven't even written one WPF application!

So all these things make me think like I am going to use all these tools, without experiencing first-hand any real world situation that cultivated the creation of them.

But at the same time, I can't try to write a huge business application in WPF without using MVVM or a good layered-design and experience all the problems people experienced in the past to appreciate all these new technologies/techniques. Because there are people out there developing stuff, getting further ahead, releasing things that work. I'll be left behind because of my obsession with trying to learn everything out there to learn. And besides, these things are not easy to learn without first experiencing the problems yourself.

But then, at the same time I have those nightmares that I start working in a new company and people tell me "You can't code your own MVVM framework? You always need to use Prism? Hahahahaha!" and they go around pointing and laughing at me in circles.

I feel like I'm a lesser programmer. I feel like I don't have what it takes to create a framework on my own. I feel like I am only able to put things together, which are created by other "better" people.

I would like to ask all the experienced people out there, what strategies have you used throughout your career? Do you always use existing frameworks? Do you create pet projects to learn about why those frameworks exist?

To make a long story short, what constitutes the thin line between using a framework and creating your own? And more importantly, how do you close the knowledge gap that automatically comes up if you use a technology/technique without seeing the real-world problems they help with?

Answer 1

Practicing doing a skill the wrong way doesn't help you learn it. You will have plenty of chances when you do it wrong by accident, or to maintain code that was done poorly by someone else.

I also find it fascinating that in these sorts of questions people only worry about the highest layer of abstraction. You're building on decades of programming language research, design paradigms, operating systems, databases, computer architecture, CMOS technology, on down, yet are only worried about not understanding the reasons for innovations in the last 10 years or so.

When people started making web pages, there was no such thing as frameworks. In another ten years, there will be improvements to things you learned the hard way, and a newbie will wonder if they understand the underlying reasons for those improvements enough, and completely take TDD, dependency injection, MVVM, etc. as a given. There are people still working who remember when there was this new-fangled notion that they should break things into relatively small functions.

In other words, don't worry about lacking the experience of the previous ten years. In the next ten years a whole new kind of experience will be required.

Answer 2

I'm a pretty new .NET developer and I'm trying to learn stuff like WPF, MVVM, layered architecture design, dependency injection, logging, database access, test-driven development, and many more different technologies/techniques.

I've seen a great talks once about how to learn something quickly (sorry, can't find it):

• Follow the 20-80 rule: learn just the 20% you need that cover 80% of the use cases. Do not get stuck in details. Understand the basics and work with those until you hit a wall. And you probably will hit the wall at some point. But you will have covered a lot of ground by then. If there's no way to cover most of your use case with little use of the tool, then it's the wrong tool for the job and chances are, there's a better one out there.
• Do not learn too many things at a time. You say right now you don't need any of the tools you think are good. That's ok. Your next step is not to try them all out at once. Pick one. The one that seems most useful for the task at hand. Apply it. When you get a grasp of it, proceed by recursion.

But then, at the same time I have those nightmares that I start working in a new company and people tell me "You can't code your own MVVM framework? You always need to use Prism? Hahahahaha!" and they go around pointing and laughing at me in circles.

I feel like I'm a lesser programmer. I feel like I don't have what it takes to create a framework on my own. I feel like I am only able to put things together, which are created by other "better" people.

A few advices, although not all are specific to programming:

1. Get rid of your ego. That's a life time challenge tackled step by step. But you will need it. If you're less worried about the image of yourself you're trying to project, you'll have more time for thinking about what you have to say. Most people will return the favor with respect.
2. The question that's really important is: What can you do? How you do it, is completely irrelevant. All that matters to your boss, your users and people who build their code on yours is how quickly you can do it (i.e how much it costs), how flexible it is in the face of changing requirements and how usable it is (from a user perspective or when interfacing from other code). Whether you use a 3rd party tool or reinvent the wheel every time from scratch doesn't matter. The perceivable consequences do.
3. Do not be bothered by assholes. The vast majority of those who have acquired noteworthy skills as developers (or any area) know how much time and work it takes. Most will go out of their way to help you if you ask them (and then really let them help you). Only a few will try to demean you. More often than not, those are the people who feel a need to compensate for their own lack of skill.
4. Do not assume that there are many people who successfully put together a "general purpose frameworks" on their own. By "successfully", I mean that people will use it and contribute to it and the mainstream will largely consider it as one of the out-of-the-box solutions for a particular problem. By that time, the project has usually been iterated for at least half a decade, having undergone constant review and enhancement by many people and with feedback of literally thousands - most of all the involved people being quite experienced. And most of the time, it's a successor or knock-off of some other technology that went through the whole maturation process already. There's no shame in using that. To the contrary: if it solves your problem, not using it is a waste of resources. It's often a sign of arrogance or ignorance or the combination of both.
   That being said: there's a lot of bloated "frameworks" out there that suck. As Douglas Adams once pointed out the titchyness of the human brain is best illustrated with how amazed it is by big things. When people see a big framework with a lot of documentation, they assume it must be good. The opposite is often true. It's often an indicator of over-engineering. But usually, for any given common problem you will often find a well-tested well-designed solution already available.

To make a long story short, what constitutes the thin line between using a framework and creating your own? And more importantly, how do you close the knowledge gap that automatically comes up if you use a technology/technique without seeing the real-world problems they help with?

1. When a tool get's the job done, use it. Understanding "the job" is the tricky thing. That's the first and most important step. Then you need to pick your tools. And then do it. And then you might realize that your understanding of "the job" just got better, so you need to add/substitute some tools and parts of the program. The likelihood of this happening is part of "the job" and is an important factor in choosing your initial toolset.
2. Would you rather have a crash in a 50 year old car to appreciate all the safety built into a modern one? I don't think so. You have your own slices of hell coming anyway. There's absolutely no need to ask for more trouble.
   You must always choose what to know, but also what not to know. This is the foundation of information hiding, which is the divide and conquer of complex systems. Your programming language already is already a big white cloud high up in the abstractosphere of planet ugglydetailia. You look at things from an abstract level, because your brain can actually only function this way. It's how you deal with the real world and it's quite sensible to apply that to programming.
   Also, knowledge in itself is worthless. Value comes from understanding. Which quite often involves the knowledge of what not to know ;)

Answer 3

Like all good programmers you're going to be continuously doing three things: learn something new, discover new problems, build solutions. The more time you spend writing code (building solutions), the better you'll get at the other two because you'll unravel new problems and learn something new that is useful.

You want to know how or when to use a new framework or methodology, but think about something a little simplier like the comment writing life-cycle:

1. Notice all published code examples comment everything.
2. Because of time constraints, useless comments, and no one reviews your code and forces you to write comments, you don't write any at all.
3. Return to old code and discover it's difficult to understand.
4. Research the best way to write comments and discover all the schools of thought: must write them or else, use a commenting tool, write self-commenting code because comments go stale, etc.

Maybe the comments aren't the problem? Like everything else, you won't get it right the first time. This is why mentors are so important (and often lacking) in the development process of new programmers. There is too much going on to trial and error everything. You could spend your whole career and never need an ORM because you never write an app that uses a database.

Wanting to learn things is a great tool for a developer as long as it is a healthy curiosity and not an obsession that prevents you from getting something built. TDD may help you since you focus on only fulfilling the requirment by coding enough to pass the test. Eventually, you'll be coding something and come to the conclusion, "There's got to be a better way of doing this." Go find a framework or just write your own.