Framework Tradeoffs For Beginners: Product Creation vs Program Maintenance

By | January 21, 2014

Phil Sturgeon at his blog, writing about product creators who neither know nor care much about programming as a discipline:

One of my close friends … is also a businessman, with a startup that is about to launch. …

He does however have literally no interest in becoming a world-class programmer. He barely even wants to code, but he can thanks to frameworks like Laravel.

… He’s written an awful lot of extremely good applications – that work – and that has made him some money. Ship ship ship.

… Does he know what separation of concerns means? Ha.

Is his code SOLID? Nope.

Is the Laravel application he made unit-testable? … no.

Is it going to function well enough to get him to his next round of funding? Absolutely. Is he going to have to throw the whole thing away? Not at all.

Frameworks are great for beginners, who literally could not possibly smash together a series of random components if they wanted to.

Phil’s post focuses on the joyful, proud moments of creation that lead to business success, whether in terms of venture funding or continued sales. In this essay, I want to focus on what happens after that, when that initial creation passes into other hands to be maintained.

The Great And Awful Thing About PHP

The great thing about PHP is that almost anyone can use it. The language and some of the frameworks based on it, such as CodeIgniter and its most-recent ideological descendant Laravel, make amateur and early-career(*) programmers productive in ways they could not be otherwise.

But the great thing about PHP is also the awful thing about PHP, and that is that anyone can use it. The beginner programmer who has been made productive by his framework-of-choice feels great pride and elation at coding an application that “works.” Soon, though, the poor practices embdedded in his work due to his inexperience will find their way through to the product presentation and affect the business. The code “works,” but not so well as first thought. The codebase now has to be maintained in order to remedy the flaws and shortcomings displayed by the product.

If the beginner programmer is the one who has to do this maintenance, and is the one to feel the pain of maintaining his own applications, then he will learn to improve his development practices. If he instead goes on to other responsibilities, he will leave behind what is most likely a mess for others to inherit. Going on to other responsibilities is almost always what happens when the business gets its “next round of funding.”

What Happens After Funding

Phil asks if the business is “going to have to throw the whole thing away” at that point and responds in the negative. Well, of course the business owners won’t discard the codebase. It doesn’t matter how bad the code happens to be, because the entire business is now dependent on it as developed by that original inexperienced programmer. Throwing it out and starting again would likely kill the business. No, what will happen is that the funding will be used to hire a team of more experienced developers to fix, add features to, and scale the code developed by the beginner programmer.

Because they enable amateurs to operate beyond their existing capabilities, frameworks like CodeIgniter and its cousins tend to make product creation easier at the expense of making program maintenance harder. (Note the difference between the concerns of the product and those of the program.) Some folks will argue this does not matter. Once the product owner gets funding, he can pay professionals to deal with the problems he created on the way to his successful round of funding.

If You’re So Smart …

From a financial standpoint, and perhaps even from an economic standpoint, it’s easy to see enabling-via-framework as a positive. Indeed, the product creator may justify his failures of good programming practice by substituting the product popularity and continued rounds of funding as a marker of success. Complaints from the development team about the codebase quality are met with variations of “If you’re so smart, how come you’re working for me?”. But from a programming practices standpoint, enabling-by-framework too often leads to pain and frustration on the part of the maintenance programmers, who are now saddled with the baggage of an amateur.

“Well, that’s their job!” comes the reply. True enough, but that does not change the fact that the codebase is terrible and tough to work with. Think what a team of developers could do with a codebase built with better practices at the time of its creation.

Footnote

(*) If one considers a professional programming career to span 20 years or more, I think it’s fair to say a developer can be considered “early-career” even with as many as 6-7 full-time years of experience in the field.

Afterword

In my 30-odd years of programming (half of that in PHP), I have been the developer in charge of improving a maintenance mess so often that I am now writing a book about how to modernize legacy applications in PHP. In it, I give step-by-step instructions on what to do and in what order. I hope it can reduce the pain that others have to suffer with their own similar codebases. Sign up below for a free chapter, updates related to publication, and more.

Sign up for Modernizing Legacy Applications in PHP:

First Name Email

35 thoughts on “Framework Tradeoffs For Beginners: Product Creation vs Program Maintenance

  1. Phil Sturgeon

    Hey Paul,

    I feel like you talk in absolutes here a few times, and say things like “of course” in places where “sometimes” would have been a better fit.

    I’ve worked for a bunch of startups who have taken very different paths through life to various levels of success.

    There is the startup that tried to build everything COMPLETELY perfectly from day one. They hired me in to “finish off some bits” about two years ago and they still haven’t launched despite me doing everything they needed. I think they might have actually shut down entirely by now. Perfect programmer approach didn’t help them there.

    There is the businessman that I was referencing as my example, who has two projects out the door and they both made him money. The level of his code was “good enough” where it was not impossible for me to tart it up a little and iron out some holes. Sure his NPath complexity is insane and it hasn’t got a single test, but thanks to following the guidelines of a “hold your hand a little” framework he was good enough to get shit done and I was able to improve it without crying.

    So we’ve had “doing it right and wasting time and money on perfection instead of shipping” and “shipping without caring about perfection”, what about the middle-ground?

    How about the company that smashed together a prototype in Rails to show their potential clients and partners how things worked, then iterated on that prototype, then used that money to hire a British programmer to come in and replace all of that fucking terrible code with a nice PHP API? Then used THAT new version to launch a product?

    My article was trying to point out how and why talking in absolutes about developers and framework usage is silly.

    Some folks were saying “beginners should never use a framework, they should learn from scratch.” with others saying “Everyone who ever tries to code should learn everything about DiC and unit-testing first.”

    I responded to that with “everyone is different, but using frameworks can drastically improve the success of a project that is being handled by a beginner developer, who may or may not care about any of that stuff.”

    Now you’re responding saying “That’s always a bad idea.”

    So that didn’t really work out, did it?

    I also assume you agree that a beginner who has not time or interest in learning advanced concepts is better off working with a framework like this, than trying to bootstrap their own way to a solution using arbitrary components? They might not learn as much, but they’ll make less of a shit-pile of it all with the docs holding their hand.

    Reply
    1. pmjones Post author

      using frameworks can drastically improve the success of a project that is being handled by a beginner developer, who may or may not care about any of that stuff.

      I am saying nothing different from that. My concentration in this post is on what happens *afterward*.

      Reply
      1. Phil Sturgeon

        Right, and you seem to think that regardless of what happens, the framework-built first version is terrible and afterwards the company is always at a loss due to this first step being done by somebody who is not an expert.

        I’m trying to point out that while not wonderful, it’s often not that much of an issue. I was saying in my article that the process of taking the code built by that inexperienced developer was not at all difficult.

        1. Throwing away a codebase for a startup is super common and not a business crippler as you suggested. Lots of startups will make a prototype and ditch it. This is a place where you say “of course” in place of “somethings”.

        2. Applications built with Laravel are (in my rather extensive experience in the area) usually good enough even if tacked together by a dummy, that they can be saved without all that much work. Facade to IoC for example is a piece of piss, and a wild NPath complexity can be saved by moving the occasional chunk of code to a few well named classes.

        I know you want this article to highlight tradeoffs, but the only mention of a trade-off is in the title. The whole way through the article it just seems to say “beginners write worse code than professionals and that is bad for business”, which is a crazy blanket statement to make when there are so many types of business and so many types of developer.

        I guess a little more direction in the article would help. :)

        Reply
        1. pmjones Post author

          “beginners write worse code than professionals and that is bad for business”

          The first part of that sentence is undeniably true. Whether it is “bad for business” is the choice each business has to make, and I say as much. This article highlights the fact that “rapid development” by amateurs is not without its costs.

          (Updated to include the phrase “by amateurs.”)

          Reply
          1. pmjones Post author

            It’s the entire article, man. For example:

            From a financial standpoint, and perhaps even from an economic standpoint, it’s easy to see enabling-via-framework as a positive. … But from a programming practices standpoint, enabling-by-framework too often leads to pain and frustration on the part of the maintenance programmers, who are now saddled with the baggage of an amateur.

            Do you need a tl;dr for something even as short as this?

  2. Michael Calkins

    This is hilarious I’m literally dealing with these problems right now. Except I’m the one who caused it and am now rescuing myself xD #growingPains ugh..

    Joel Hooks from egghead.io recently created an article about code rescue and the tools he uses to avoid it. Despite his main income is from rescuing other people’s projects now.

    Can’t wait for your book Paul!

    Reply
    1. pmjones Post author

      I’m literally dealing with these problems right now. Except I’m the one who caused it and am now rescuing myself

      I’ve been there myself; thus this post. Good luck man! ;-)

      Reply
  3. Amy Stephen

    Paul – I am afraid I don’t get your logic. Basically, I hear you saying that PHP and PHP frameworks that are easy to use help newbies be productive but they end up writing bad code. So, is your point all frameworks should be difficult to use in order to raise the bar so newbies aren’t able to use the tool (and therefore, they can’t write bad code?) Is Aura that complex that it eliminates the learner crowd? And that’s intentional?

    I also have 30 years of experience in development, titles that would impress, but I’m not afraid of learners. I believe tools that make it more productive for their involvement help build the future for the language. Yes, they will make mistakes, but that’s where a friendly, constructive, active community comes in. A good way to judge that is to look at what resources a community makes available for learners — are there lots of books? Podcasts? Conferences? If so, trust the process.

    Soon, those of us who wrote code for 30 years will be eating soup and complaining about young people. We got to make room.

    Reply
    1. pmjones Post author

      Hi Amy,

      I hear you saying that PHP and PHP frameworks that are easy to use help newbies be productive but they end up writing bad code.

      Yes, I think you hear me correctly.

      So, is your point all frameworks should be difficult to use in order to raise the bar so newbies aren’t able to use the tool (and therefore, they can’t write bad code?)

      It is not. I neither state nor imply any recommendation here, other than to keep in mind that there are tradeoffs, and that the amateur *is still an amateur*.

      Is Aura that complex that it eliminates the learner crowd?

      Aura is probably not for people who (quoting Phil here) “have literally no interest in becoming a world-class programmer.” It is more directed at the maintainers I describe in the post.

      Reply
      1. Amy Stephen

        You seem to be suggesting a great developer with experience and skill would avoid choosing a tool on the basis that the tool is easy to use. That’s what is not connecting the dots for me. If your point is that hiring beginners could result in an inferior result (regardless of the tool they use), then, sure. But, is that really a question?

        I’ve heard these arguments for years where it is suggested productivity tools is harmful for the industry. When we went from Assembler to COBOL, the concern was developers would not understand how to create registries and the lack of comprehension on how memory storage and retrieval works would result in bad code. I remember the push back with COBOL code generators and reaction of “real developers” when tools like Visual Basic were introduced.

        Guess I don’t see how Aura is complex to use. As it gains adoption and builds its community of developers, tools, documentation, books, videos, etc., will be available and that will help build momentum and make it for newbies to jump in and quickly produce results. It’s easy to do (once you know how to do it. ;-) ).

        So, sure, beginners are likely to produce results with lower quality and maintainability. But, that is true regardless of the tool. It is equally true that good developers benefit from productivity enhancements, and can do so without sacrificing innovation, scalability, or quality.

        Reply
        1. pmjones Post author

          You seem to be suggesting a great developer with experience and skill would avoid choosing a tool on the basis that the tool is easy to use.

          I suggest no such thing.

          If your point is that hiring beginners…

          At no time do I mention “hiring beginners.”

          it is suggested productivity tools is harmful for the industry

          I make no such suggestion. I point only to the tradeoffs involved.

          I don’t see how Aura is complex to use.

          I suppose it requires more from the developer using it, but no, I don’t see how it’s overly-complex either. Others may differ.

          beginners are likely to produce results with lower quality and maintainability. But, that is true regardless of the tool

          Agreed! It’s not the framework, it’s the developer. Having said that, some frameworks cater to amateur and early-career developers, so one must take that into consideration as well.

          Reply
          1. Amy Stephen

            Last comment, don’t want to make you defensive or frustrated or give you the impression I am arguing with you. I just don’t get the point.

            I agree with you that low product creation cost MIGHT hide product flaws that are costly in maintenance. On the other hand, I’ve helped implement SAP, so, I know from personal experience it does not necessarily follow that non-newbie-friendly translates to low maintenance costs. Agreed?

            In my opinion, you’ve made a claim, but not presented evidence. For example, rather than simply assert Aura is geared towards “maintainers”, first, establish what work is involved in maintenance. Then, describe what it is in Aura provides that assists with the maintenance effort. That way, you start to build helpful metrics that could then be used to contrast with a competitor.

            Personally, I don’t even know that we have established what is “easier for newbies.”

            That’s what I mean by “not connecting the dots.” It would be interesting to start building a database of those types of metrics. Collectively, we might actually learn something from that exercise and maybe build better software. Just not seeing that in this piece.

            Thanks for your patience with my feedback. =)

          2. pmjones Post author

            I just don’t get the point.

            I don’t know how much more clear I can make it: amateurs who are enabled by frameworks to develop a successful product quickly still write amateur code. That code is going to be less maintainable than it would be if it had been written by professionals. I fail to see how this is at all a controversial subject. All I have done here is point out what anyone who has had to maintain legacy codebases developed by non-professional programmers already knows to be true, and what Phil states to be true in the parts of his post that I quote; to wit: no separation of concerns, not SOLID, not unit-testable.

  4. pmjones Post author

    See the blog tagline: “there are no solutions, only tradeoffs.” This entry is about the tension between creation and maintenance.

    (UPDATE: Hell, the word “tradeoffs” is even in the title of the post.)

    Reply
  5. Adam Wathan

    To say that “frameworks like CodeIgniter and its cousins tend to make product creation easier at the expense of making program maintenance harder,” is not accurate in my opinion. I think an inexperienced programmer with a framework will be able to write something that is much easier for me to maintain than an inexperienced programmer slopping away with no guidelines or pre-existing structure to follow.

    People who want to build products with PHP will still figure out a way to do it if you don’t give them a framework, and the result is going to be a million times worse than it would have been with something like Laravel or Codeigniter.

    I agree 100% that the low barrier-to-entry is PHP’s biggest problem, but it’s a problem with the language and not with the frameworks. Rails makes it easy for people to build applications too, but you can’t just name a file .rb and upload it to ShittyHost.com and have it work, so it keeps the amateurs away.

    Reply
  6. pmjones Post author

    Hi Adam,

    To say that “frameworks like CodeIgniter and its cousins tend to make product creation easier at the expense of making program maintenance harder,” is not accurate in my opinion. I think an inexperienced programmer with a framework will be able to write something that is much easier for me to maintain than an inexperienced programmer slopping away with no guidelines or pre-existing structure to follow.

    Perhaps. It’s been my experience applications built in the “typical PHP page-based include-oriented” fashion have been easier to pick apart and refactor than those based on frameworks. At the very least, the “inexperienced programmer slopping away” is more likely to be aware of his inexperience, and keep it in mind while doing his work, than a developer who has discovered “the new hotness.” (Note also the caveat “tend to.” ;-)

    People who want to build products with PHP will still figure out a way to do it if you don’t give them a framework, and the result is going to be a million times worse than it would have been with something like Laravel or Codeigniter.

    Maybe. But the point here is that using the framework (whatever it might be) is not a panacea. You get a lot of power up front, but you end up with a different set of problems later. That’s the tradeoff: a more-quickly-developed product from non-professionals that gets you maintenance trouble later, vs a less-quickly-developed product from professionals that is easier to maintain. One gets to pick, but one should not pretend that there aren’t costs to both.

    I agree 100% that the low barrier-to-entry is PHP’s biggest problem, but it’s a problem with the language and not with the frameworks.

    The problem, such as it is, lies neither with the language nor the frameworks, but with the developers using them.

    Reply
    1. Adam Wathan

      I guess my perspective is somewhat different, as I have had to work on a lot of inherited projects where a bunch of co-op students tried to build a web application on top of a WordPress install, with plenty of mysql_query calls directly in the templates. Or function calls in the middle of a template that take 15 arguments and then ‘global’ 8 more variables at the beginning of the function. That is the sort of nightmare that PHP allows that I think you would find less often in PHP projects that are built on top of a framework that provides some sort of inherit organization and conventions. I could show you some truly horrifying stuff :/

      You’re right that it’s not really a problem of PHP as a language and that the problem is the developers. I mispoke when I said “the problem is with the language”; I really meant that the problem is with the PHP ecosystem for lack of a better word. The super low barrier-to-entry, crappy outdated resources and pollution of the talent pool with inexperienced developers who came from the wrong side of web development and never really learned how to actually write software.

      My experiences with inheriting legacy PHP projects have just given me the opposite opinion I guess. I would much rather inherit a Laravel project from an inexperienced developer where there was at least a baseline level of organization so at least I knew where to start trying to understand the code base.

      I think we can both agree though that crappy hard-to-maintain code is crappy hard-to-maintain code :) It’s probably easier to avoid if we just move to a different language that does a better job of keeping out the inexperienced developers.

      Reply
      1. pmjones Post author

        Hi Adam,

        I have had to work on a lot of inherited projects where a bunch of co-op students tried to build a web application on top of a WordPress install

        You have my sincere and proufound sympathies, sir.

        Even so, one can read this as proving my point. Some frameworks (and we’ll call WordPress a stand-in for a framework here) attract amateur, early-career, or otherwise junior developers. If the students had been working on something from scratch my bet is that it would still be awful, but probably better than strong-arming something into WordPress.

        I could show you some truly horrifying stuff :/

        “I’ve seen things you people wouldn’t believe.”

        You’re right that it’s not really a problem of PHP as a language and that the problem is the developers. I mispoke when I said “the problem is with the language”; I really meant that the problem is with the PHP ecosystem for lack of a better word. The super low barrier-to-entry, crappy outdated resources and pollution of the talent pool with inexperienced developers who came from the wrong side of web development and never really learned how to actually write software.

        Dude, I totally get you on this, and I concur.

        My experiences with inheriting legacy PHP projects have just given me the opposite opinion I guess. I would much rather inherit a Laravel project from an inexperienced developer where there was at least a baseline level of organization so at least I knew where to start trying to understand the code base.

        /me nods

        For my part, inheriting CodeIgniter projects was often less painful than inheriting ZF1 or (horrors) Symfony 1.

        I think we can both agree though that crappy hard-to-maintain code is crappy hard-to-maintain code :)

        Agreed!

        It’s probably easier to avoid if we just move to a different language that does a better job of keeping out the inexperienced developers.

        Well, like I say, there’s a tradeoff: you can have quick productivity at the cost of later maintenance headaches, and sometime’s that is the right tradeoff. But let’s not think “I can make an app today and ship tomorrow!” is without its downsides.

        Reply
  7. Greg

    You conflate ease of development with reduction in long term maintainability and I think this is inaccurate. I also think that the perpetuation of this kind of debate is a problem which keeps the crowd of “frameworks suck” (in general) fuelled..

    As a developer with many years of experience, and as a technical lead and project manager with almost a decade of experience on top of that, across multiple languages, the only conclusion that I can draw is “bad developers write bad code irrespective of the tools they use”. However, both good AND bad developers can be more productive using a framework.

    From a business perspective productivity is immensely important. From a developer perspective maintainability and testability is immensely important. Often these 2 goals are in conflict. Frameworks buy you a *hope* that you can have your cake and eat it too. Will bad developers still write garbage? of course. But garbage within a framework is much easier to refactor than garbage outside of one. Good developers will be productive regardless.

    > , frameworks like CodeIgniter and its cousins tend to make product creation easier at the expense of making program maintenance harder. (Note the difference between the concerns of the product and those of the program.)

    I assume you are referring to program in the project management sense – the whole of life of something which is made up of multiple projects that may or may not involve one or many products? If that is the case then I think you are wrong. Experience tells me you are wrong. Products written using frameworks (in any language, not limited to PHP) tend to reduce the TCO, and reduce long term costs due to a substantial reduction in technical debt.

    I appreciate what you are trying to say in this article but your points about maintainability vs productivity being somehow diametrically opposed when they are in fact orthogonal to each other does not play out in reality in my experience.

    Reply
  8. Pingback: Paul Jones: Framework Tradeoffs For Beginners: Product Creation vs Program Maintenance | htaccess

  9. Pingback: Paul Jones: Framework Tradeoffs For Beginners: Product Creation vs Program Maintenance | facebooklikes

  10. Jeff Walters

    Nice article Paul. I’ve seen this way too many times. I’ve even had to re-work entire projects written mainly with procedural code. But, that’s where a simple MVC framework such as CodeIgniter can really help. It allows us to refactor the code, without having to rewrite everything. Of course, explaining to management why you need to refactor code “that works” is the real challenge.

    Reply
  11. Nodex

    Abstracting code to a framework for amateurs is chicken and egg. There are certain reoccurring problems in app development that need to be fundamentally understood and that can ONLY be done by having not only a deep understanding of the language but also the complexities associated with the various fixes.

    Now without being able to earn money there is likely little motivation for a new programmer to want to sift and wade through PHP’s documentation and trial & error fixes for problems they don’t even know exist yet.

    I have been fortunate in that I have NEVER used a framework for anything, I have gone out and researched all possible solutions and built my own (often better for my project) solution.

    Also what needs to be thought about is not just PHP or “Application” code but also full stack as in how to interact with caches, how to output valid and optimsed html etc etc, which is something that is very abstracted when working with frameworks that include templating engines.

    When the full stack in understood at a proper level only then can applications be efficient and this cannot be achieved without understanding ALL aspects of an application including the vanilla language – in this case PHP.

    Reply
  12. John Secada

    Paul,

    If more than one person are telling you something, maybe they are right, especially when they are equally experts as you are. It’s ok to consider the other person’s point.

    We all can always learn from each other. I feel like your replies have been more on the defensive side.

    Thanks for taking time to write on the subject. I love you, brother.

    Reply
    1. pmjones Post author

      Hi John,

      Yours is a totally fair point, and (believe me) well-received. I’m aware of the effect my writing style has on some people.

      Even so, when the “more than one person” are repeatedly the same persons, or are persons from the same crowd, then I am perhaps less inclined to see it as a failing on my part. Or, maybe it’s a failing to get through to certain types of people. For good or bad, I can’t reach everyone. There are many who *do* get me, and I’ll continue to write for those people.

      Regardless, I appreciate your civil tone here, and I thank you.

      Reply
  13. Antonio Garcia

    Hi
    I read the sample chapter and is very interesting.
    Where is the goal ? projects with mysql_query everywhere? based in a framework ? both ?
    What are the differences between Codeigniter and Solar ? (Aura is PHP 5.4 and is out of comparaison).
    It’s not possible take Solar or Aura and create a “bad” project in maintenance terms?

    Awaiting for the TOC of your book. Thanks

    Reply
    1. pmjones Post author

      Hi Antonio,

      Where is the goal ? projects with mysql_query everywhere? based in a framework ? both ?

      The target is people dealing with “legacy applications”, loosely defined as those projects with an “include-oriented” architecture (as vs a “class-oriented” architecture). What does “include-oriented” mean? See this old presentation of mine about organizing PHP projects (skip to slide 24 if you like). It does not directly target legacy framework applications, as each framework seems to have its own distinct legacy issues. Perhaps separate books for Symfony 1, Code Igniter 1, Cake 1, ZF 1, Solar, etc. would be warranted.

      It’s not possible take Solar or Aura and create a “bad” project in maintenance terms?

      Oh, it’s *very* possible. I’d argue it’s more likely with Solar, seeing as how it used Service Locator everywhere instead of Dependency Injection proper. Either way, the issue is the developer, not the framework. An advanced developer using CodeIgniter or something like it would build much better applications than an amateur one. The problem is that some projects attract a more junior crowd, and some (I flatter myself that Aura is in this camp) attract a more senior crowd.

      Reply
      1. Antonio Garcia

        Thank for the response.

        Codeigniter “won” the battle of frameworks pre 5.3 with a great guide (or maybe the tab with slide effect), a forum and 1 product based (expresion engine).
        Laravel is 5.3+ and use more advanced techniques but take advantage of codeigniter die and is succeeding (marketing based in fan is the best) with books,videocasts,twitter RTs and more (It’s a very very good work).
        AuraPHP need a “bit” of marketing IMHO.

        Reply
        1. pmjones Post author

          Antonio:

          AuraPHP need a “bit” of marketing IMHO.

          No doubt. :-)

          Reply
  14. Boabramah Ernest

    You see Paul, If I’m the guy with the money, I will hire someone who can deliver the product within the time frame. The business guys do not care about cyclomatic complexity issues or dependency injection. Its the money. So if later I have to hire a professional developer to fix the code to now support 10,000 request per seconds or whatever number, why not. Considering the tradeoffs I will go this way. And I think That is what MARK did with facebook. If they had that professional knowledge at that time, I do not think they would have used PHP in the first place. Now they have created HHVM by the professionals to deal with the shortcomings of PHP. GUESS what thier plan has worked well for them.

    Again, I do not know if I should label someone who uses codeigniter and it’s cousins to be an amature or newbie as you put it. At least the person might have known PHP basics, MVC, maybe finished his or her TRIED AND FAILED FRAMEWORK (TAFF) project. I do not think code written by someone with this background will be bad at all. if AURAPHP should get the needed marketing boost and resources available it will soon become the playground of amature and newbies.

    Paul, remember when you were once an amature and you wrote shitty code and someone had to clean it up. There will always be amatures and professionals. And Business will have to make the choice. But as always money is first.

    Reply
  15. Brad B

    Good stuff, I have seen this general flavor floating around for a while, but in slightly different terms. Something like a framework != good Architecture. In fact, I prefer using micro frameworks as they do what I need them to do and get the heck out of the way for everything else and don’t create directory structures full of garbage.
    I can say I have seen my fair share of poorly developed applications some within frameworks some not within frameworks, and to be honest being developed in a framework does not make it suck less.

    Although we should still celebrate creation, but it’s important for people to not get lazy and create crap just because it is easy.

    Reply
  16. Alex

    I have to say, there are some good observations in this post with regard to taking a framework and producing code that would be miserable to maintain over the long term.

    There’s an interesting phenomenon of frameworks actually being able to reduce the skill level of existing programmers too! Perfectly familiar senior-level PHP programmers will pick up a new framework, commit all kinds of atrocities and then leave the mess behind them. Usually because they think they know everything.

    What it really boils down to – and maybe you’re eluding to this – is just good software design principles. Whether you’ve got 10 years or 0 years of experience behind you, using a framework is about research and buy-in. The beginner programmer is at no less a disadvantage than the senior PHP scripter who uses constants for everything.

    Not 100% certain where I’m going with this except that there’s an obligation for anyone using any tool to use it properly.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *