I’m a software engineer, not a computer scientist. I studied software engineering at university and that’s what my degree says, Software Engineering, not Computer Science. But, what is the difference, after all, we’re all programmers, aren’t we?
A scientist observes, performs research, formulates hypothesis and tests them with experiments. Scientists discover new things and new ways of achieving things. They grow our knowledge and enable us to mentally evolve as a species.
Engineers take what scientists have proven and apply it to real world problems. A scientist can’t fix your car, but an engineer can (don’t tell me that your dad/cousin/mum/uncle/friend/pet-cat is a scientist and has fixed your car — I’m only really talking to the grown-ups). Engineers don’t really invent anything new (that’s what inventors do), they prefer to use tried and tested techniques to solve problems. They are problem solvers, and their tools are handed to them by scientists.
Now, I’m not really talking about which degree you have — basically they’re all the same in the end; I’ve worked with geologists who have made great programmers. I’m talking about the role you assume on a software development project. If you’re a programmer, then unless you’re in a research role somewhere you’re probably practicing as an engineer, and you should behave like one. Your duty is to provide maximum value for money to the person who hired you — whatever that means in your particular circumstances.
(If you work with Gradle, you’re probably going to want to navigate away from this page right now, it wasn’t written for you, it was written for the grown-ups). And don’t bother trying to flame me, I have moderator status on the comments and I won’t waste more than a second deleting your comments, I have no interest in them and if you think I should have then you haven’t been paying attention).
This means that, for most of us, we shouldn’t be playing with new technology at work. I used the word playing there — if you’re a professional engineer and you’re using, for example, Gradle, then you’re playing around with toys when you should be doing your job. You are better advised to use Maven, because it’s very popular, there’s lots of help, it’s been used to manage millions of projects in many different situations, and you can hire people off the street who will know it. This isn’t true of Gradle.
Notice that in the previous paragraph I didn’t perform a technical comparison between Gradle and Maven. That’s not my job — that’s a scientists job — and I have no interest in whether Gradle is technically superior or not. My job is to ensure that the systems I create are useful and maintainable. As long as a tool is fit for purpose it’s up for consideration, and I’m sure Gradle, like Ant, is fit for purpose. Hers’ the questions a senior engineer asks:
How easy/hard is it to hire people with good knowledge of this tool/technology? If it’s not popular then I will find it very difficult to hire for this skill, either permanently or temporarily. For example, I write my systems in Java because there are ten-times more java programmers than all other languages added together. I use Maven for the same reason. I don’t use Gradle because it’s really only popular with people who are asking the wrong questions. If you’re using gradle and you object to this last sentence, then you’re wrong, get over it. I don’t really care what you’re doing with it, you’re still wrong because you’re answering the wrong questions. Stop being a geek, lift up your head and answer the important questions.
How easily can I get help if I’m stuck? I’ll stick with the Maven/Gradle discussion, because it’s a growing concern at the time of writing. Maven is used on most projects, while Gradle is used on few. There is little real-world experience with it. There is very little help beyond some very basic documentation. If something is broken, then the chances of finding a solution quickly is very limited. Maven is so popular that almost everything that can go wrong has actually already gone wrong, and then the people it went wrong for ranted about it on Stack Overflow and the problem was documented, along with its solutions – how useful is that? Very.
How good a fit is this tool to our puroposes and what will our productivity be like if we use it? Are there any holes in the workflow of the tool? Does it integrate with the other tools on my project?
Is this a mature product? By mature I mean all of the above — people, help, problems — and I mean to ask if all the major defects have been worked out of the system? Is there a vibrant and active community of users extending the capability of the tool? Is there a body of professional knowledge — books, websites, forums, videos, best-practices and cookbooks, where I can go for inspiration, guidance, and help? Is there a mature enterprise class organisation out there offering professional support contracts? I won’t bang on about Maven and Gradle again, the answer should be self-evident at this point.
This is how an engineer thinks. The technical questions, beyond basic fitness for purpose, aren’t really that useful. I don’t care that one language is more elegant than the other unless it has a huge impact on productivity — I’m much more interested if I can actually hire someone who can write code in it. I don’t care that the artifacts consume less memory — I care that there are deep defects in the system that nobody has found yet because it hasn’t really been used in anger in a complex enterprise setting.
I don’t want to sound like I’m crushing innovation. I’m really not — I adopted Spring after it had been on the market for only a year. I stuck with it, despite the emergence of a technically superior competitor for google, and in inferior one from the JCP, because by the time competitors arrived Spring had the market share it needed to win out on all the categories above. I adopted Spring early only because it was disruptive and it was obviously the right thing to do, this is not true of most other tools/projects/technologies and the questions posed here are usually the right ones to ask, especially when someone is paying for your advice.