I work as an all-round back-end and front-end web developer in a medium sized IT company where, for the last 3 months (when other projects don’t fly into the middle), I have been working together with an architect in building from scratch the new version of the main software of the company. They have chosen to build a framework from scratch, which I am doing. At this point we have something pretty powerful and developer-friendly starting to surface. It is fair enough that the less technical people of the company have started wondering after so long, and are now putting our approach in doubt, asking why haven’t we chosen to use an framework like Symphony, which would have greatly eased the process and saved a lot of money to the company.
If you ask me I’m pretty satisfied to give only one reason:
I wouldn’t wanna put the whole business at risk by making the main business driver software sit on top of an open source framework, because when vulnerabilities are exposed your business is exposed to hackers before you can deploy an update, and even if we would be 24/7 alert for new vulnerabilities and updates it is not always that straight forward to update, and in medium and big sized companies you sometimes have to follow relatively lengthy processes before you can push the update to production. Open source software releases many updates often so therefore there would be many vulnerability windows throughout the business life.
Even though I’m satisfied to defend our approach with only this reason I would appreciate new perspectives and further points to defend or attack our approach so that when the moment comes for us to defend ourselves we have plenty of material to do so.
You fellows would rock if you could contribute some ideas.
The obvious is that a custom framework removes much of the bloat of open source “general use” frameworks. You decide what features are built in, and how it is built. Less bloat means less complexity, and (generally) better performance.
Another reason is environment requirements. Most frameworks require X-version of X to be installed; and usually it is an outdated version, since these frameworks tend to compromise between backwards compatibility and new features. Since you mentioned Symfony, I assume this is a PHP framework…you can install PHP ver 5.6 on your server and start developing around that and taking advantage of the new language, rather than coding like it is 2009.
Those are reasons enough to DIY, but I’ll be happy to give more if you need them.
Thanks for the insights, really appreciated. I knew all of them but for sure I would have missed one or two points, that’s why I asked. More is welcome for sure. I sent my C.E.O. a list with two points I came up with and 2 you mentioned, briefly:
To be brutally honest I’m not sure if this argument holds anymore. In “ye olden days” we used to have only big frameworks like Zend, Symfony, Cake, CI, etc, which all contained a lot of overhead and components you didn’t really need.
But, nowadays there are a lot of lightweight frameworks (or micro frameworks if you will), like slim , [URL=“http://silex.sensiolabs.org/”]silex, [URL=“http://li3.me/”]lithium, etc.
With those frameworks, you can choose which parts you want to use, and discard any other parts, or replace them with something you built yourself, like a custom router, stuff like that.
That, combined with composer gives you a lot of power to swap out components every which way you please, combining the best of all worlds for your specific purpose.
Of course the argument “people can exploit it if they know what I’m running” may still hold (arguably, since I find that people are testing stuff more and more and better every day, to the point where they’re running more test than you’d ever manage to write), but “I want to make this framework so that it adheres to what I want, instead of what the original authors of the framework had in mind” is no longer valid in this day and age. At least not as far as I’m concerned.
Not to rain on your parade; if you’ve made something that’s easy to be used by all developers, and you’ve written a lot of tests for it, and it does what it’s supposed to do, then by all means go for it! I only wanted to point out that times have changed and DYI isn’t the be all end all it used to be.
I definitely agree with that. When taking on something like a custom framework, there should be very good reasons to go that route, as opposed to what is already available. There are certainly a lot of checkmarks under the “Reasons not to do it” column
The code ownership / avoidance of licensing is probably the biggest thing I would sell to your boss. That is absolutely a big concern.
Back to being the skeptical bossman…
I appreciate the responses, however, I still am not completely comfortable with questions 2 & 3. I need more details to feel secure about the direction of my company.
Who are these testers, and what are these automated tests? What are these tests looking for, and where are they applied? Remember, my job is to count money and sail around the world in my yacht, so you are speaking alien to me.
What is the plan for scaling the software? Are you going to throw my money at more hardware every time the server locks up? This fellow I know, arout77, he is also building a framework, and he informed me that one of the strategies he is implementing is to use Mongo as the database, and take advantage of memcached to create a cheap cluster that will be trivial to add more servers to, should the need ever arise. Do you have a similiar solution?