Tech Off Thread

5 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Drag and Drop Code

Back to Forum: Tech Off
  • User profile image
    AndyStewart

    Hi Guys

    Quick questions for the coders, I've recently joined a new company and I just want to make sure I'm not going mad. But this place does an awful lot of drag and drop coding (ie DataAdapters/DataSets/any shortcuts that could be made), where as I'd always write code and abstract away the DataAccess/Business logic(le Olde Fashioned Way)

    I'm right in saying this drag and drop fashion is a bad way to write code, and that this should only be used for quick hacks, or has there been a change in programming methods while I slept the other night.

    All opinions welcome, as they all look at me strange and I think I'm going mad.

    Andy


  • User profile image
    Dr Herbie

    AndyStewart wrote:
    Hi Guys

    Quick questions for the coders, I've recently joined a new company and I just want to make sure I'm not going mad. But this place does an awful lot of drag and drop coding (ie DataAdapters/DataSets/any shortcuts that could be made), where as I'd always write code and abstract away the DataAccess/Business logic(le Olde Fashioned Way)

    I'm right in saying this drag and drop fashion is a bad way to write code, and that this should only be used for quick hacks, or has there been a change in programming methods while I slept the other night.

    All opinions welcome, as they all look at me strange and I think I'm going mad.

    Andy




    Depends on the purpose of the software.  Some software is for critical systems, some is not.  Some software is expected to be maintained for many years, some is not. Some software is large and complex, some is not.

    Drag and drop programming is not 'bad', it is simply not always appropriate. 
    Likewise, doing the whole DataAccess/Business logic is also not always appropriate. It may give you a warm feeling of a job well done, but in business you have to be pragmatic.  A 'good' (well engineered) job to you may be a 'bad' (expensive and late) job in business.

    What sort of software are they writing?


    Dr Herbie



  • User profile image
    AndyStewart

    Mainly coding inhouse "business apps", mainly dataretrieval and manipulation. Just would of thought a well engineered app would scale better and be easier to maintain. But I'm always willing to be proven wrong.

    Andy

  • User profile image
    AndyStewart

    AndyStewart wrote:
    Mainly coding inhouse "business apps", mainly dataretrieval and manipulation. Just would of thought a well engineered app would scale better and be easier to maintain. But I'm always willing to be proven wrong.

    Andy



    Also these are the apps that the core of our business runs on and is meant to be maintained and ran for a long time.

  • User profile image
    Dr Herbie

    AndyStewart wrote:
    AndyStewart wrote:Mainly coding inhouse "business apps", mainly dataretrieval and manipulation. Just would of thought a well engineered app would scale better and be easier to maintain. But I'm always willing to be proven wrong.

    Andy



    Also these are the apps that the core of our business runs on and is meant to be maintained and ran for a long time.


    What methodology do they use?  If it's agile/extreme programming then their main concern will be to get something working first, then leave refactoring until maintenance becomes a problem.  This avoids 'over-design' and increases productivity.  It's not a method I tend to use, but I'm comming round to a softer version of it - I try and get the high-level architecture up front and don't worry about implementation details until I find problems, then refactor the problem areas to a more design-pattern system (see 'refactoring to design patterns' book).


    On the other hand, there may be valid reasons for this sub-optimal stance.  I used to work as a contractor and saw many dev deparments.  I would very often think "What a stupid way to do things" when I first arrived.  I'm happy to say that most of the time there were valid reasons for what they were doing.
    Whatever you do, don't tell them there's a better way, you'll just wind them up.  Try asking loaded questions instead: 'Does that scale well?'; 'Have you throught about a scalable framework?'; etc.  This will show that you have thought about the problems without appearing arrogant.

    If all else fails, do your best (within whatever restrictions are placed on you) do write code the way you think best.  If it really is better, they will notice.

    Herbie


    PS: Always look at the business angle, it can surprise you.  It may be cheaper in the long-run to do things the way they do, without checking the business angle you can't be sure.


Conversation locked

This conversation has been locked by the site admins. No new comments can be made.