Having many years of experience writing code for various domains, I think the article needs some more specificity. I do agree, you cannot always predict what the business might want, but you are the technologist and can see further into technology and the future than the business can sometimes. Don't simply abrogate your responsibility to create value for the company by anticipating needs and/or designing extensible software even when you think there will never be another need. Yes, you don't know what you don't know...and neither does the business. But they rely on good engineers to help guide them. Here's my mantra that has served me and the companies I have worked for well:
There's no such things as "throw-away" code.
That's hyperbole for sure, but it establishes a mindset of craftsmanship versus that of a handyman.
An example from years past comes to mind. I was asked to participate in a project that created an external floppy disk drive system with an embedded Z-80 based computer system. The system used a chip that controlled the stepper motor and the reading/writing of data to a single sided floppy disk capable of storing 360K of data. The chip however was capable of doing half steps giving 720K of data (if the media quality supported that density). It was also capable of writing to both sides of a disk. For those old enough to recall you needed a little notch in the floppy do allow a sensor to detect that the media was double sided. Even though our team was given the single-sided 360K requirement we knew that someday we'd be asked to take full advantage of the hardware. Adding the additional code to the firmware was fairly trivial and we along with the hardware guys added a feature switch (I think that's what the kids call it today?) using a jumper on the motherboard that would turn on the new modes.
In my opinion, the difference between programmers and engineers is encapsulated in how one views their expected contribution to the company. If you expect to be paid for satisfying today's requirements and you write software that way - you are a programmer. If you use technology to solve today's problems while considering how that technology can be extended, leveraged and create additional value for the company you work for, you're probably an engineer. And it's not always about creating monetary value. Engineers have changed the world by innovating and doing more than was asked even before the lever.
If all we do is ...build the simplest version possible we may miss opportunities to create something that can be easily leveraged with minimal effort for even more value.
Having said all of that, I will finish by sharing my other mantra:
Don't build brick outhouses.
My two mantras may sound contradictory, but they are not. Build software that satisfies the requirements in the simplest and most efficient way. That is different than build the software that only satisfies the stated requirements. One last thought associated with building well designed, solid systems. The design is not complete when you have added the last component, it's done when you've removed the unnecessary ones.
In summary, I think the author's use of such an extreme view is not compatible with my philosophy and what has made me successful in my career (ymmv). We may simply disagree with regard to what is necessary to satisfy the requirement and create a well designed extensible system.
