The Difference Between IT and Software Engineering
-
@QuixoticJeremy said in The Difference Between IT and Software Engineering:
@scottalanmiller said in The Difference Between IT and Software Engineering:
@QuixoticJeremy said in The Difference Between IT and Software Engineering:
@scottalanmiller Exactly, it makes them bad at both and is dangerous for the deployment process etc. Something is likely to get screwed up because people aren't as knowledgeable and results in a waste of time and money fixing something that should have been handled by people dedicated to that particular operation/department. Not to mention if software engineers are spending their time doing that, they are doing less coding. This slows down the SDLC and also slows down their learning and makes them worse developers.
Task switching kills productivity. And thinking about dev work and thinking about operations are major context switches.
lol heck, just switching from being in ML back to my dev work kills my productivity
ha
-
@QuixoticJeremy said in The Difference Between IT and Software Engineering:
@scottalanmiller said in The Difference Between IT and Software Engineering:
@QuixoticJeremy said in The Difference Between IT and Software Engineering:
@scottalanmiller Exactly, it makes them bad at both and is dangerous for the deployment process etc. Something is likely to get screwed up because people aren't as knowledgeable and results in a waste of time and money fixing something that should have been handled by people dedicated to that particular operation/department. Not to mention if software engineers are spending their time doing that, they are doing less coding. This slows down the SDLC and also slows down their learning and makes them worse developers.
Task switching kills productivity. And thinking about dev work and thinking about operations are major context switches.
lol heck, just switching from being in ML back to my dev work kills my productivity
Not mine... *presses shift+delete *
Well, crap. I didn't mean to delete THAT folder.
-
This might be going down a rabbit hole, but how about test environments? I imagine IT would install and configure the test severs which mimic production environment (and from what's mentioned before, deploy an application build created by the devs to that test environment. I also know that a dev would have a local environment (Visual Studio + IIS express + SQL server) where they're doing their day-to-day coding and testing. Would setting up that environment on their machine be the task of IT?
-
@EddieJennings Actually a test environment is usually not even worth it because it requires so much $ to keep up to date and mirror what you have. It can be, but usually isn't.
-
@EddieJennings said in The Difference Between IT and Software Engineering:
This might be going down a rabbit hole, but how about test environments? I imagine IT would install and configure the test severs which mimic production environment (and from what's mentioned before, deploy an application build created by the devs to that test environment. I also know that a dev would have a local environment (Visual Studio + IIS express + SQL server) where they're doing their day-to-day coding and testing. Would setting up that environment on their machine be the task of IT?
Delivery of IT infrastructure is the key here.
A developer doesn't develop in thin air so, yeah IT would have the responsibility here to ensure that the infrastructure is ready for dev.
-
@wirestyle22 said in The Difference Between IT and Software Engineering:
@EddieJennings Actually a test environment is usually not even worth it because it requires so much $ to keep up to date and mirror what you have. It can be, but usually isn't.
Depends what you are testing. Code is always worth testing before going to production
-
@wirestyle22 said in The Difference Between IT and Software Engineering:
@EddieJennings Actually a test environment is usually not even worth it because it requires so much $ to keep up to date and mirror what you have. It can be, but usually isn't.
This sounds odd to me. Especially since devs likely (as our's do) have MSDN subscriptions in order to have access to Visual Studio (notwithstanding the free edition), so MSDN would grant the Windows server licenses necessary to license the test environment. Yes -- licensing isn't the only cost associated with creating a testing environment
-
@scottalanmiller @wirestyle22 We have local test environments along side of test servers. It's always worth being able to test before going to prod.
-
@EddieJennings said in The Difference Between IT and Software Engineering:
@wirestyle22 said in The Difference Between IT and Software Engineering:
@EddieJennings Actually a test environment is usually not even worth it because it requires so much $ to keep up to date and mirror what you have. It can be, but usually isn't.
This sounds odd to me. Especially since devs likely (as our's do) have MSDN subscriptions in order to have access to Visual Studio (notwithstanding the free edition), so MSDN would grant the Windows server licenses necessary to license the test environment. Yes -- licensing isn't the only cost associated with creating a testing environment
If you're testing code its different. I'm talking from an SMB perspective as well
-
@EddieJennings said in The Difference Between IT and Software Engineering:
This might be going down a rabbit hole, but how about test environments? I imagine IT would install and configure the test severs which mimic production environment (and from what's mentioned before, deploy an application build created by the devs to that test environment. I also know that a dev would have a local environment (Visual Studio + IIS express + SQL server) where they're doing their day-to-day coding and testing. Would setting up that environment on their machine be the task of IT?
Test can obvioulsy be handled by either, but it's only sensible for IT to do it. If IT doesn't do it, how much are you really testing?
-
@EddieJennings If IT doesn't do it then there could be environmental factors that weren't set up identically to prod that could influence who code runs, thus creating bugs and wasted time once the code hits production.
