This doesn't just apply to cars either. Let's talk about a project that I have had to help on and a horror story or two. I have always heard the running joke about software being enterprise, hell you can do a quick Google search and find many examples of joke about this. Here, have one! This is the concept of making things over complicated because....reasons! We can discuss the why later, right now let us begin on a story of one of the first "enterprise" applications that I had the fortune of helping write.
Warning! The next paragraph is going to be a long one.
So the first time that I was introduced to this concept was helping with an excel spreadsheet. Yes, even a spreadsheet can be overly complicated. This spreadsheet was used to write contracts for multi MILLION dollar agreements. This spreadsheet had been around for about 15 or so years being updated through the versions of Excel over time. When I got to it the year was 2010, Excel was 2003. Already I am having a bad time. This spreadsheet took a lot of time to learn, it was pretty massive to say the least. The main problem, it didn't need to be, The bulk of the spreadsheet was about 25 columns wide and only 20 rows tall, or so I thought. I began exploring the Macros and found that there were only 2 macros. I thought this would be cake. One macro was to add a new row or column on a button click for more items or a custom field. The second macro was to save. Pretty simple so far. The save button called to run a formula inside of a cell. Let's go look at this cell. This is where dread began to set in, as I realized that I couldn't find the cell. I was looking for R7, the only problem is that my columns went to N...then jumped to BM....fuck. At this point I had no clue what I was about to uncover when I unhid those columns. What was hiding was a monster. A monster that no man could stop as it flew about the room. A monster of such twists and turns one might think it was made of spaghetti. In these columns were all the formulas to calculate payments on these contracts. Each cell was a concatenation of another. Since this was Excell each cell could only hold 256 characters. Not sure if that limit has gone up or not. Anyway, each cell would be calling multiple cells to build out its formula, and each of those cells would do the same. This was how the original developer got around the 256 character limit. By spreading his "code" across 50 columns. This made my small enhancement that should have taken a day or two turn into a week or two. Since I now have to figure out what is all going on in each cell. I ended up just printing out the contents of each of those cells and making a sort of map to figure out what cells talked with each other. I wish I still had my map, but it was taken from me when I left the project. The other developer thought I was a genius for making this map. I thought I was just being punished for kicking a puppy in a past life.
Now if you skipped that last paragraph, just know that code was written in an overly complicated way and I hated my life.
So how does something end up like this? Clearly the original developer knew macros were a thing, but chose not to use them here. I like to think that it started with just a few cells because it was quicker to put it there than write a macro and things got out of hand. I have done that myself and understand how that can quickly become a monster. But at a point you have to refactor. I have even heard some people boast at how complicated their code is and all I can think is, "why are you proud of this?" Seriously, I might be alone on this, but I am rarely impressed by complicated code. You want to impress me, show me how to take that 100 lines of code and drop it to 10. Take that 1000 lines and find a way to get it below 200. Then I am impressed. So why do some people think over complication is a good thing?
I can think of two schools of thought on this, and I am sure there are plenty of other anecdotal reasons for this than mine, but I have two; And they both seem to revolve around job security. You make things so complicated that nobody else can do your job. This will get you so far. Because all it takes is a new developer, and the idea of completely rebuilding a new application and you're out of a job. Or, the more likely the scenario. A new developer who is coding things simpler, and finishing way ahead of schedule because people are used to your slow ass taking for ever.
The second is "security", I use quotes because it is only security by obscurity. Which is a good process, as long as it isn't your only process. Some people like the idea that it takes a lot of time for a malicious individual to find their way around your application. At the same time, it will take a new guy just as long to learn the code, if not longer. I say longer not because the malicious individual is smarter, but because this person is motivated to learn the code. Meanwhile, new guy is ready to bail on the project and call the recruiter back by day 2.
So let's wrangle up this post with some key points and give a half assed TL:DR to balance out the post about over assing something..
- Don't write complicated code if you don't have to
- Just because you can do something, doesn't mean you should
- Don't mistake malice with ignorance, and vice versa
- Make changing a headlight easier than this!
No comments:
Post a Comment