The Difference Between IT and Software Engineering
-
@QuixoticJeremy said in The Difference Between IT and Software Engineering:
Yes, we would often call them the engineering department (except in Oregon where engineer is a negative term for legal reasons) or a development department or something similar. Whoever they report up to is doing the role of the CTO.
Yep, we're the engineering department here. Environment issues get handled by IT where code related issues get handled by us (beyond normal development). IT also handles all maintenance of environments in terms of the servers themselves, application deployments, migrations etc (normal responsibilities of IT).
That was going to be my next question / observation. For the actual deployment of the application, here is what happens for us (mind you I'm on a 5 man team: me + 4 devs. The devs have a script that turns their solution from Visual Studio into a .zip file that's the web application. They also have a deployment script, which they run on IIS server, that takes the .zip file and extracts the pieces of the application to the appropriate places and configures IIS.
With properly separated roles, it seems that IT be the folks that takes the built application (.zip file) and install it on the IIS server (run the aforementioned deployment script). Probably the reason why all of this happens with the devs is before my time, there was basically one person handling dev and IT.
-
@EddieJennings said in The Difference Between IT and Software Engineering:
@QuixoticJeremy said in The Difference Between IT and Software Engineering:
Yes, we would often call them the engineering department (except in Oregon where engineer is a negative term for legal reasons) or a development department or something similar. Whoever they report up to is doing the role of the CTO.
Yep, we're the engineering department here. Environment issues get handled by IT where code related issues get handled by us (beyond normal development). IT also handles all maintenance of environments in terms of the servers themselves, application deployments, migrations etc (normal responsibilities of IT).
That was going to be my next question / observation. For the actual deployment of the application, here is what happens for us (mind you I'm on a 5 man team: me + 4 devs. The devs have a script that turns their solution from Visual Studio into a .zip file that's the web application. They also have a deployment script, which they run on IIS server, that takes the .zip file and extracts the pieces of the application to the appropriate places and configures IIS.
With properly separated roles, it seems that IT be the folks that takes the built application (.zip file) and install it on the IIS server (run the aforementioned deployment script). Probably the reason why all of this happens with the devs is before my time, there was basically one person handling dev and IT.
Right, you have a merged department. Your IT and SE people are wearing both hats, generally a bad combination. The needs and skills of each role are very different.
-
Devs, for example, don't need an operational mindset. IT needs nothing else, mostly. Putting people in a position to have to switch in and out of operations is risky, it makes them bad at both.
-
@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.
-
@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.
-
@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
-
@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.
