A Note to My Fellow Application Developers about Knowing Our Limits

  • Comments posted to this topic are about the item A Note to My Fellow Application Developers about Knowing Our Limits

  • I agree with this editorial. Most of my career has been spent in small shops where you become a jack-of-all-trades. One thing is very important; do not be arrogant and think you know everything. You have to know what you don't know and be comfortable with revealing that to management. Bring expertise in when necessary.

  • we have an IT dept of about 70. We have a lot of very talented & knowledgable people, but so far as I can tell there is only 1 person who is genuinely a specialist. David is our Exchange guy. If something can be done with Exchange, David can do it, without a reference manual or even google. There is no-one else in the department with such an in-depth knowledge of a single system or subject. My colleague Pete knows a lot more SQL Server stuff than me and has MCTS as a DBA but there are still areas that he sometimes defers to me on.

    The problem (its a problem in my opinion, but others see it as a benefit) for us is that the department has, on purpose, made everyone a generalist. We are 'analyst programmers', meaning that we (theoretically) do 50% bau and 50% development. the development bit is completely end-to end. we draw up the TOR, BRD, functional spec and documentation as well as getting involved with physical server requirements and configuration as well as developing the software front-end and database backend and even manage our own backups and maintenance.

    the end result is that if 1 or 2 'developers' were involved in a project, both those individuals will be 'familiar' with the entire end to end process and able to provide BAU support for it.

    My view is that we should instead have a BAU team and provided there is adequate documentation from the developers, dba, tech servs etc they should be perfectly capable of supporting it.

    Nevermind eh, Rome didnt conquer europe in a day, I should be grateful we actually HAVE BRDs at last!

    Ben

    ^ Thats me!

    ----------------------------------------
    01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
    ----------------------------------------

  • If you're an employee or sub-contractor, then you can (and should) acknowledge the need for external expertise, but that decision is ultimately out of your hands.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Ya, I had to get out of being a jack-of-all trades. It was great to learn a bunch of different stuff of course, but the problem was, I learned that the VAST majority of jobs were looking for specialists in .NET or SQL or a network engineer, and a minimal amount were looking for people who could do both or all 3. (But the ones that did typically had the higher pay rate). Oh, and it was a pain to get certified in numerous languages/platforms, and people still expected that you were a true expert in all. I just like having the title of DBA now with the understood expectation that this is my area of expertise, although, in reality, 80% of my job is probably .NET or SharePoint development related. At least I'm not required to get certified in those on my own time.

  • Question Guy (6/2/2011)


    Ya, I had to get out of being a jack-of-all trades. It was great to learn a bunch of different stuff of course, but the problem was, I learned that the VAST majority of jobs were looking for specialists in .NET or SQL or a network engineer, and a minimal amount were looking for people who could do both or all 3. (But the ones that did typically had the higher pay rate). Oh, and it was a pain to get certified in numerous languages/platforms, and people still expected that you were a true expert in all. I just like having the title of DBA now with the understood expectation that this is my area of expertise, although, in reality, 80% of my job is probably .NET or SharePoint development related. At least I'm not required to get certified in those on my own time.

    Being a Jack-Of-All is useful for landing a short term gig when one is between honeypots. If one can code ASP.NET, SYSADMIN SQL Server, and QA your own work, while being proficient enough to get the job done without major problems, then that really improves one's chances of landing a gig. However, you're correct that most of these jobs are not something one would want to keep long term.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Overall I agree, however I am Leary of outsourcing something as critical as backups and disaster recovery. I would outsource development or support work before I would outsource backups. If something goes wrong it is not the outside consultant's primary\only job that is on the line, nor is it his company that could loose thousands or more dollars in lost revenue etc...

    Hire an outside consultant to train you how to handle backups etc... if needed but in the end this is a responsibility that I would keep in house.

  • krowley (6/2/2011)


    Overall I agree, however I am Leary of outsourcing something as critical as backups and disaster recovery. I would outsource development or support work before I would outsource backups. If something goes wrong it is not the outside consultant's primary\only job that is on the line, nor is it his company that could loose thousands or more dollars in lost revenue etc...

    Hire an outside consultant to train you how to handle backups etc... if needed but in the end this is a responsibility that I would keep in house.

    +1 !

    Ben

    ^ Thats me!

    ----------------------------------------
    01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
    ----------------------------------------

  • One of the problems I think we all run into is that many (most?) people outside IT already think we're already specialists: computers. If a computer is in any way part of the job, somehow that makes us an expert in the job. Windows, Mac, Linux; servers, workstations, dumb terminals; smartphone, feature phone with a browser; network cabling, switches, routers; databases, cameras, phone systems, accounting systems, video post-production, every single feature of every application installed on every system.

    And it's not just my mom or some random dude I met at a party. Most of my managers have had trouble understanding that developer and Photoshop guru are different let alone developer and DBA.

  • krowley and BenWard,

    I hear you! The approach you suggest of keeping production DBA responsibilities in-house and outsourcing the development functions makes perfect sense. However, my education, experience, expertise, and interest is in application and database development. For some in my position, outsourcing skills that we have and enjoy while maintaining responsibility for skills that we have yet to develop--especially skills as critical as those underdiscussion--may not appeal.

    Your approach is also related to the issue of trust. Can we trust the people or organizations that we would outsource production DBA responsibilites to? That's a very reasonable concern that each person has to answer for himself or herself. In our case, the production DBA we hired sat on the board of the Professional Association of SQL Server, has been a Microsoft MVP for several years running, is well-known on the Microsoft/PASS speaking circuit, and has proven himself knowledgeable and reliable on the projects he's completed for us. We decided that we're better off hiring him do the things that he does well while allowing me to continue doing the things that I do well.

    Again, your approach is equally valid. The important thing is that, at the end of the day, our employer's data is adequately protected.

    Thanks!

    Chris O'Connor

  • Good article. And good discussion. Your point “Don’t risk more than you can afford to lose” is so fundamental to the developer and DBA, but also the business. I would just add that it is important to communicate with the business managers when risk is identified. The DBA, developers, or IT staff, may not be able to properly assess exactly the risk or what a company can afford to lose for a particular company.

  • Good article. The danger with being a jack-of-all-trades is that you tend to be spread very thinly and important tasks get skipped (like backups). That said, there is value in being a specialist in one area and a generalist in related areas. Like being a SQL specialist and a Windows generalist. There's no arguing the value of that combo.


    James Stover, McDBA

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply