As I move through my career, there are a few guidelines I have summarized for how I should write software:
- Make it work
- Do it correctly so that it is:
- Testable
- Maintainable
- Use the right tools
But, what is it about using the right tools? I have gotten consistently confused growing up in this job about all these tools out there. It is impossible to write code that is maintainable, and it makes it increasingly difficult to make the product testable and work right if I use the wrong tools. There are all these new fangled projects people do that gain traction because of young, naive crowds. New programmers buzz about them on Twitter or write articles about how awesome they are because they seems to "interesting." At my job we use the .NET stack, and that is really all we need for the job. I have gotten excited about new languages and new ways of doing things, but what is the point? It just causes me to slow down in development time. And, how long will these technologies last? There are tools out there like Python and Lisp, but those are not appropriate with SQL Server, the application server we use and the other developers on my team. I do experiment outside of my job and my boss is open to new ideas, but for the most part, none of these tools are worth it. It all depends on what we are trying to do. I tried using Signal R to do something like notify the managers when an employee does certain things that are "off" on our standalone logistics system, but what is the point? In a business perspective, it would slow the managers down to have things popping up that they don't need to see right away, and there are other ways of notifying them besides introducing a newer technology that is sparkly and blingy. How will the others on the team learn it quickly? How will a new developer learn it quickly? I have looked at GraphQL for doing APIs that will have a cleaner URL for our web application, but just for that? A cleaner URL? Or, we have looked at Single Page Applications. They are very trendy. We could make really cool features. But, it is not easily testable and hard to upgrade. Who knows if the technology will last? The Request/Response model with POSTs has been around for years and years and probably is not going anywhere at all. It is really all we need for our purposes.
There was a time when I wrote Prison Management software. The prison wanted to take the cheaper way out and use Salesforce instead of making a Java Web Application for their online system. This was probably not for the best, but the stakeholders cried out that they wanted something "affordable." My team spent much of our time augmenting Salesforce to do our bidding to get the features out there. We accomplished it, but as the project went on, things took longer and longer and the Prison System spent sooo much money. And, who is going to maintain it? My corporation? No way! I would never have been happy to be stuck in that situation. It is unnatural. How would you connect anything new with such a custom behemoth. And, it was very ugly looking, too. For users that know little about using computers, and their staff did (some of them had no computers at home). The usability was very, very poor, and training probably cost a boatload because of that, too. This was a horrible tool for the job. Using a newer tool can be awful, but as an architect, it isn't possible to just listen to your own advice; the customer is always right.
As I was studying advanced features of C# this weekend and over the past month, I learned about things you can do with C# like make delegates, lambda expressions, functional interfaces, anonymous functions, events, overload operators, and write extension methods for classes. This is good and all, but it is clear that I would probably never use these things for my current job unless there is a specific use case for it. If I used these things regularly, it would make the code very hard to read, test, and maintain. I can see younger developers messing around with these things and making the software "work" with them, but there is absolutely no need 99% of the time. Maybe if someone is developing features for the language itself or working with complex math these things would be necessary. They advertise some of these things as making it quicker to develop, however, in the long run they would lead to more technical debt.
It probably is good to seek out new technology and ideas, though. There are new things what will take flight and land somewhere to last a while. Research must be done. Things like Git have taken the industry like a storm. It had to have started from somewhere. Linus Torvalds is a smart man. I wonder, with my limited experience, how long we should wait for a new tech to be used before we take it up. Who knows if we won't use NoSQL databases in my job. Python is mute because we already have Powershell. There is nothing wrong with having Microsoft tools. They do the job. And, they are great for business programming. Heck, I am writing this from an Ubuntu laptop, so you can't say that I am a Windows advocate. Linux is fast, reliable, secure, and awesome. I run a Linux server for my website and blog. It is much, much easier to use IMHO than an IIS server. I use those at work, though. I do. We have taken in security considerations and how everything works together. I did not make those decisions in the first place, but I trust my boss.
Corporations will take on all kinds of third party softwares to put together their infrastructures to make things "easier" and more "efficient." Are they? Does it really make things better? Connecting the tools and not having control of features doesn't seem right to me, but with all the thousands of voices out there that want this or that, it seems that having a monolith that supports 95% of what the company needs would suffice. I just know that my company is small and we can afford to have software that is made custom, in shop for our users, the internal ops. My company prides itself in being the best at what we do, and as an IT team, we do things that really help. The systems we create streamline the process of our business.
I will continue to look into new tools. As I grow, and I move forward to being more in charge at my job, it is imperative. As I see more and more tools out there, my experience leads me to be less naive. It isn't true that we always have what we need. Some new ideas or new frameworks/projects out there could benefit. It just takes time and effort to peruse through the news and see what others have done. Just recently I had to make design decisions for a feature and I see more clearly how I have to have knowledge and wisdom to know what to do. There is a big difference between a junior developer, staff engineer, and architect. I guess that is why there is such a difference in pay grade. It has always frustrated me that I cannot just read a bunch of things in books to get better at writing and designing software. It takes being in the trenches and time. That is the only real teacher.