The Blog Battle title for this week is “Engineering Over/Under”, and I thought I’d simply share my own experiences/inadequacies with this problem. As a young engineer (I am 23 and graduated roughly a year and a half ago), I have struggled much more with under-engineering, rather than over-engineering, but feel like I have some insights to share on both.
Under-Engineering…
is the tendency to over-simplify an issue/problem and introduce code that is inflexible, hard to read and/or hard to test. In my first few months on the job out of college, I undoubtedly introduced some of this code, and so did all of us. That’s one of the reasons why we have code review policies which require the code be viewed by another. I remember my early code review comments, numbering in length between 20-30 (well-deserved) suggestions and analyzing every one of them for where I went wrong. If it were not for these suggestions and my desire to learn from them, I would be months behind where I am today.
What to do?
First, learn from your mistakes. Find the patterns in your code reviews you receive and try to reduce the number of comments like it you receive. I got a lot of ‘Unit test this case’ until I started reviewing my own code and writing unit tests for every path I could find. Do this for all of your common comments, and ask questions on those comments you don’t understand. Taking this kind of initiative not only allows you to get better at your craft, but shows your team that you care about improving yourself and the quality of the product.
Next, get to know your client/users. The better you can anticipate how they’ll use the software, the better you can find the right fit for the work you about to do. If you know the users tend to ask for a filterable data export, spend a bit of extra time making your search query reusable for the export, and you won’t have to double that amount of work. Just be careful not to over-engineer…
Over-Engineering…
is the tendency to over-think a problem and introduce code that is more complicated than necessary, resulting in putting too much time and effort into a feature than necessary. Wikipedia will gladly redirect you to an article on value engineering, which, to summarize, is the maximization of the ratio of function to cost. The less money that’s spent providing a valuable product to the users – the more money the company makes. The more money the company makes, the more employees they can hire, the more products they can undertake, the more profitable everyone becomes.
Over-engineering, then, leads to more complicated code to maintain and more upfront money spent – providing no additional value. We could provide only features as they are requested, which would be best for the bottom line at the moment, or, we can spend a little bit of money now and save some time later.
What to do?
Sit down and ask yourself what the customer really needs, and if you can’t answer in a single sentence, then I can’t give you an answer here. Sometimes it’s best to hold off until they ask or are willing to pay, and others it’s best to anticipate their needs. In the end, it’s a judgement call. If you aren’t sure about this decision, ask your manager – that’s why they’re there.
Of course, there’s some gray area here. I speak from the perspective of an engineer providing a service, so as a disclaimer, not everything I’ve stated may be best for you, your company or your household pets.
