Skip to main content
Software Engineering

Return to Answer

added 4139 characters in body
Source Link
openai_sucks
openai_sucks
  • 1.3k
  • 7
  • 12

Using an existing CMS framework inevitably inverts the priorities. Instead of focusing on building a system around your core 10% of unique functionality, will now be focused on trying to jam your square peg 10% to fit into the round hole of the 90% the CMS provides.

This changes the way you think about your project. Now, instead of thinking about creating something tailored for your needs, you will unavoidably find yourself thinking about how to bend your needs to fit the flow of the frameworkexisting CMS. You will do this because anything else means swimming upstream.

These difficulties will occur despite the very best efforts to generalize the CMS framework (which I'll refer to as just a "framework" here). Because you can't have a completely generalized framework without having the full expressive power of the underlying programming language allowed within the framework.

Let's also not forget that years from now, you will be at the frameworkCMS maintainer's mercy for updates or else you must maintain a copy of the frameworkCMS yourself.

Some CMSs and/or frameworks are written so well that you can use them as libraries (or so I've heard).

Using an existing frameworkCMS often seems less scary. But it shouldn't be. It should be horrifying.

Update:

I'm glad you've included some specific features in your question. It will help my answer look a little less like a manifesto and more like a contrarian form of pragmatism.

  • Custom menu - There is no question that this will be harder to implement as a module for an existing CMS than it would be if it were simply part of a from-scratch project. An intimate knowledge of the CMS module API will certainly be needed. I'm hopeful, but skeptical that there's a CMS out there that would make this pleasant to integrate.
  • User system - This is the perfect example of a really hard problem when trying to interface different systems. It's not that you couldn't create a hack to make it work - I'm more concerned about the long-term maintenance of such a system. Software doesn't have to be monolithic, but if it's going to share responsibilities with other software, there needs to be a clear divide between the two systems. Anything else scares me because of fragility. You'd have to investigate externalizing the entire user system in the CMS - if there's a solid mechanism for doing so, you'll then have to determine the level of effort to implement the "client" side of that communication on your existing user system.
  • Third party data - Clearly this is going to be more custom modules and, unless you can find existing modules for the CMS and the third party data sources in question, you're going to have to write them yourself (it sounds to me as if you already know you'd end up writing these yourselves). There's no question it will involve more effort up front to implement these as CMS modules. To be fair, the extra effort may be a blessing down the road as building the modules will require you to properly encapsulate the communication - something you would not be required to do when creating from-scratch sites. (That's what good, old-fashioned discipline is for, right?)
  • Multi-site/multi-language - if there's a CMS which already supports this, it may give you an instant leg-up. If there isn't, I can't imagine adding it would require anything less than mucking about in the CMS's internals. Perhaps you could bend an existing feature such as tagging into service to help? (Ah, but here I am trying to shape the problem to the CMS, rather than the other way around. A lesser person than myself might say something pithy like "QED" here.)

There are an additional two parts from your original question which I neglected to address before:

  • Security - Yes, a system is only as secure as its weakest link, and that could include shoddily-written modules. Furthermore, more code is more potentially insecure code. Even with a ton of volunteer eyes, an existing CMS is still a whole lot of lines of code you and your team didn't write.
  • Server load - I could see this going either way - the CMS may have had quite a bit of work put into this area already (caching, etc.), so you might have an advantage from the outset. On the other hand, if you're running into specific problems, it will be far easier to fix them in your own code than hunting them down in the CMS (and getting them approved and pushed back upstream - and failing that, do you maintain your own fork?).

Updated conclusion

At worst, it would definitely pay to at least look at the existing CMSs as if they were a collection of parts to be sifted through, looking for diamonds. It's likely that no single open-source CMS supports everything you need, but one of them might have a really nice solution for at least part of it. One with, say, an MIT license would allow you to grab a feature you like and use it in a library-like fashion in your own framework.

I think your question is already well-reasoned and full of healthy skepticism. Deciding whether or not to use 3rd party software is super hard. It's like choosing between having a dangerous animal as a pet or being all alone on a solo journey to Mars. You're either going to live with some fear of being eaten, or you're gonna be lonely.

Using an existing CMS framework inevitably inverts the priorities. Instead of focusing on building a system around your core 10% of unique functionality, will now be focused on trying to jam your square peg 10% to fit into the round hole of the 90% the CMS provides.

This changes the way you think about your project. Now, instead of thinking about creating something tailored for your needs, you will unavoidably find yourself thinking about how to bend your needs to fit the flow of the framework. You will do this because anything else means swimming upstream.

These difficulties will occur despite the very best efforts to generalize the CMS framework. Because you can't have a completely generalized framework without having the full expressive power of the underlying programming language allowed within the framework.

Let's also not forget that years from now, you will be at the framework maintainer's mercy for updates or else you must maintain a copy of the framework yourself.

Some frameworks are written so well that you can use them as libraries (or so I've heard).

Using an existing framework often seems less scary. But it shouldn't be. It should be horrifying.

Using an existing CMS inevitably inverts the priorities. Instead of focusing on building a system around your core 10% of unique functionality, will now be focused on trying to jam your square peg 10% to fit into the round hole of the 90% the CMS provides.

This changes the way you think about your project. Now, instead of thinking about creating something tailored for your needs, you will unavoidably find yourself thinking about how to bend your needs to fit the flow of the existing CMS. You will do this because anything else means swimming upstream.

These difficulties will occur despite the very best efforts to generalize the CMS framework (which I'll refer to as just a "framework" here). Because you can't have a completely generalized framework without having the full expressive power of the underlying programming language allowed within the framework.

Let's also not forget that years from now, you will be at the CMS maintainer's mercy for updates or else you must maintain a copy of the CMS yourself.

Some CMSs and/or frameworks are written so well that you can use them as libraries (or so I've heard).

Using an existing CMS often seems less scary. But it shouldn't be. It should be horrifying.

Update:

I'm glad you've included some specific features in your question. It will help my answer look a little less like a manifesto and more like a contrarian form of pragmatism.

  • Custom menu - There is no question that this will be harder to implement as a module for an existing CMS than it would be if it were simply part of a from-scratch project. An intimate knowledge of the CMS module API will certainly be needed. I'm hopeful, but skeptical that there's a CMS out there that would make this pleasant to integrate.
  • User system - This is the perfect example of a really hard problem when trying to interface different systems. It's not that you couldn't create a hack to make it work - I'm more concerned about the long-term maintenance of such a system. Software doesn't have to be monolithic, but if it's going to share responsibilities with other software, there needs to be a clear divide between the two systems. Anything else scares me because of fragility. You'd have to investigate externalizing the entire user system in the CMS - if there's a solid mechanism for doing so, you'll then have to determine the level of effort to implement the "client" side of that communication on your existing user system.
  • Third party data - Clearly this is going to be more custom modules and, unless you can find existing modules for the CMS and the third party data sources in question, you're going to have to write them yourself (it sounds to me as if you already know you'd end up writing these yourselves). There's no question it will involve more effort up front to implement these as CMS modules. To be fair, the extra effort may be a blessing down the road as building the modules will require you to properly encapsulate the communication - something you would not be required to do when creating from-scratch sites. (That's what good, old-fashioned discipline is for, right?)
  • Multi-site/multi-language - if there's a CMS which already supports this, it may give you an instant leg-up. If there isn't, I can't imagine adding it would require anything less than mucking about in the CMS's internals. Perhaps you could bend an existing feature such as tagging into service to help? (Ah, but here I am trying to shape the problem to the CMS, rather than the other way around. A lesser person than myself might say something pithy like "QED" here.)

There are an additional two parts from your original question which I neglected to address before:

  • Security - Yes, a system is only as secure as its weakest link, and that could include shoddily-written modules. Furthermore, more code is more potentially insecure code. Even with a ton of volunteer eyes, an existing CMS is still a whole lot of lines of code you and your team didn't write.
  • Server load - I could see this going either way - the CMS may have had quite a bit of work put into this area already (caching, etc.), so you might have an advantage from the outset. On the other hand, if you're running into specific problems, it will be far easier to fix them in your own code than hunting them down in the CMS (and getting them approved and pushed back upstream - and failing that, do you maintain your own fork?).

Updated conclusion

At worst, it would definitely pay to at least look at the existing CMSs as if they were a collection of parts to be sifted through, looking for diamonds. It's likely that no single open-source CMS supports everything you need, but one of them might have a really nice solution for at least part of it. One with, say, an MIT license would allow you to grab a feature you like and use it in a library-like fashion in your own framework.

I think your question is already well-reasoned and full of healthy skepticism. Deciding whether or not to use 3rd party software is super hard. It's like choosing between having a dangerous animal as a pet or being all alone on a solo journey to Mars. You're either going to live with some fear of being eaten, or you're gonna be lonely.

Source Link
openai_sucks
openai_sucks
  • 1.3k
  • 7
  • 12

You'd be crazy to write a CMS from scratch. My kind of crazy.

3rd party software is baggage.

We all depend on some amount of baggage; it's unavoidable (unless you are Charles H. Moore and write everything down to the hardware level).

Pick your baggage carefully.

Is 90% enough?

An open-source CMS probably covers 90% of the functionality your website needs. So, clearly you will save a lot of time getting that 90% for free right up front.

But there's an immediate downside. You have to learn the CMS. This is a non-recoverable expenditure of effort.

The next, much more serious downside: I believe you should always be focusing on the 10% that is unique to your website. That's the important part. That's the part without which, there would be absolutely no need for your site at all. In fact, the 10% is really all that matters. Without that, you actually have nothing.

Using an existing CMS framework inevitably inverts the priorities. Instead of focusing on building a system around your core 10% of unique functionality, will now be focused on trying to jam your square peg 10% to fit into the round hole of the 90% the CMS provides.

This changes the way you think about your project. Now, instead of thinking about creating something tailored for your needs, you will unavoidably find yourself thinking about how to bend your needs to fit the flow of the framework. You will do this because anything else means swimming upstream.

The Framework Dilemma

These difficulties will occur despite the very best efforts to generalize the CMS framework. Because you can't have a completely generalized framework without having the full expressive power of the underlying programming language allowed within the framework.

Having the full power of the underlying programming language means losing the advantages of having a framework in the first place - its ease of use! Now you have two complicated things to learn rather than just one. The knowledge of the framework isn't even portable.

So to avoid the extreme end of the continuum, frameworks must avoid being completely generalized and are therefore cannot be a perfect fit for every project.

There's probably a name for this dilemma. (And if there isn't, it's called "The Framework Dilemma" and you read it here first.)

There are advantages to frameworks, of course. You're getting all sorts of wonderful, tested functionality straight out of the box.

But it's still baggage and (if you're really, truly using it properly) you're still having to learn almost as much as if you'd written it yourself. And most of your learning will specific to that framework!

Let's also not forget that years from now, you will be at the framework maintainer's mercy for updates or else you must maintain a copy of the framework yourself.

It's a difficult calculation to know if you've gained enough in trade.

A template analogy

Consider a template language:

There are moments in your life when creating your own template system is the most wonderful thing. You can create a tiny, readable, and beautiful syntax specific to your problem. It saves you time, its more readable. It's glorious.

Nobody else has written this template language before because nobody has solved this exact problem before. (If they had, you wouldn't be writing this software in the first place!)

Well, since it worked so wonderfully the first time, you decide to apply the same template language to another project. Its needs are 90% similar and you don't want to maintain two separate template engines that are 90% similar because that won't be DRY. So you make the template language a little more generalized.

Sure, the new template language is harder to read and write because its more general, but it's easy enough and it still works great. Two projects are using it and your glory has been nearly doubled!

Add a third project that is 90% similar to the first two. And then a fourth. And a fifth. Oh, and your friend wants to use it with her project, so now there are six 90% similar uses. Your template language has become almost completely generalized.

All this while, the template language has been moving down the continuum from a simple, perfect fit, towards the inevitable "Turing-complete one-size-fits all instrument to rule them all." Inch by inch.

Until one day, you realize that you must hang your head in shame. Because as your beautiful little solution has evolved piecemeal over time to accommodate all of the different needs, it has now actually become harder to learn, to read, and to write than the programming language on which it was built.

Realizing this, you scrap the whole idea and go back to writing everything by hand. On paper. With an inkpot and quill.

Don't reinvent the wheel

Are you actually making a garden-variety wheel? You're making a huge mistake if you reinvent the wheel in production. (You should definitely reinvent the wheel now and then for hobby projects.)

For the sake of all that is good, don't write your own general-purpose CMS to solve this problem. If you do that, you really would be better off using a battle-tested existing CMS.

If you're going to write your own software, make it a 100% fit for your project. Lest you end up like the template language analogy above.

You're not making a wheel. You're making a machine with a very specific purpose. Use existing wheels.

Use libraries

Libraries allow you to use existing quality code, but in a way that lets you assemble the provided "90%" around the 10% core of your custom functionality.

A good library does not dictate your software architecture. You can keep your priorities where they belong: your "10%".

Libraries don't dictate your database schema. There is no substitute for a well-designed database schema.

Libraries are still baggage. Pick your baggage carefully. Don't pick something huge if something small will work. You may end up having to maintain the library yourself someday.

Don't write your own crypto algorithms.

Some frameworks are written so well that you can use them as libraries (or so I've heard).

Comparing with the physical world

You can do a lot with a screwdriver, a hammer, and a pair of pliers. If you were dropped on an island with just these tools, you could accomplish just about anything with them.

But these three are absolutely not ideal tools for anything other than driving a screw with a specific head shape and material, driving a nail of a certain size and weight, or grasping a part of a specific size, shape, and material.

When quality, efficiency, and safety matter, there are specialized tools in the physical world. We take this for granted. I cannot for the life of me understand why people think software is any different.

A generalized CMS is a very basic tool set. It is wonderful when it's what you need. It's not the right tool set for every job. Sometimes you really do need a pneumatic flooring nailer or a watchmaker's lathe.

Conclusion

Using an existing framework often seems less scary. But it shouldn't be. It should be horrifying.