One thing I'm starting to notice is that it is much harder to write software now than it was 4 years ago. Am I becoming incompetent? Hardly, I think I'm a much better developer now than I was then. The "problem" is that my company has grown from a single table database with maybe 100,000 records to an unknown number of tables with tens of millions of records. Back in the day, it was easy to churn out a piece of software because things were much simpler.
- The impact of my software was minimal. I was writing things that weren't directly tied to revenue. Most of my development was data analysis and simple data importing and exporting into that single table. A lot of the data was crap already and there wasn't much I could do worse than what was already there.
- My software had no other systems to integrate with. After all, I was paving new ground with what I was doing for my company. There was nothing else to maintain other than this crappy software I was writing at the time.
Now there are many things that have to be considered when writing software within my company's environment. There are several different systems which share data. I have to be very cautious about what my software touches to keep from disturbing other processes. Suddenly we now have so much software that maintenance becomes a concern. Copy and paste works fine (It's still a bad idea!) if you have 2 programs. Copy and paste becomes a nightmare when you have 100's of things. The same thing goes for embedded logic. You can get away with a crappy check for a specific login to do something special with small environment. In a big environment, that kind of stuff won't cut it. No one will remember it's there and it will undoubtedly rear it's ugly head later on.
So, the most frustrating thing in all of this is having to justify the increased time and resources required to complete tasks. When someone says something like "Let's make this button for this one login do this special thing", it makes me want to cringe. Great, now I need to create a mechanism to be able to do "special things" and stub this into perfectly normal code. And since we can't embed client specific logic and data into the code, we must make a place to store that "special thing". And since "special things" are forgotten by developers, then we must create an interface for someone to manage these things of special nature. All of this for one client who probably isn't that big and definitely not worth the effort required to do something stupid that doesn't make sense anyway. 4 years ago I wouldn't have thought twice about completing said request, and I would have just opened up the code and typed up "if(stupidClient) specialThing(); else normalThing();", compiled that and deployed it. I still find those beauties every once in a while and want to punch myself in the face for having done that.
Now instead of getting praise for quickly doing things, I'm greeted with the phrase "All you need to do is have it do this when this person is logged in and clicks this." Yes, I'm aware that is what the result should be. That is evident, but what isn't always evident is the implementation. It's hard to convey to those making these decisions why it isn't so simple. If it sounds simple, then it must be simple, right? I wish that were the case. Every decision about changes or updates to a piece of software have to be considered and weighed carefully. It's very easy to take a piece of good software that's easy to maintain and turn it into and nightmare over the course of a few feature requests.
Subscribe
Comments(0) 
