The Difference Between IT and Software Engineering
-
-
@scottalanmiller Great points here. IT and Software Engineering are extremely different but also the culture behind each side of this coin is very different like you said. As someone who has worked on both sides of this coin your point that most on the IT side have at least some programming experience where most software engineers tend to have very little to no IT experience is very accurate. This makes it very interesting when you have software engineers trying to support their own software, reason being they tend to not have the experience to deal with environmental issues that come up (or at least that's what I see happen fairly regularly).
-
Clear points. I'm seeing how this applies to an environment similar to mine.
The company is based around an ASP.NET web application. The developers work on the code for the application itself, including the queries the application will make against a SQL server database. Would IT be the folks who have installed and configured Windows Server, IIS, and SQL Server?
-
@EddieJennings said in The Difference Between IT and Software Engineering:
Would IT be the folks who have installed and configured Windows Server, IIS, and SQL Server?
Correct. Supporting developers is a huge component of what IT does in larger shops.
-
@EddieJennings said in The Difference Between IT and Software Engineering:
The company is based around an ASP.NET web application. The developers work on the code for the application itself, including the queries the application will make against a SQL server database.
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.
-
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).
-
@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.
