I've seen it a lot lately. People who have never seen a well-built application in their lives are the lead programmers at companies. Then, when a new programmer comes in, and tries to fix things, or tries to do new things better than the ways it has been done before, the wall of "This is how the rest of it is done, and we want it to conform" is thrown up. Now, not only have you proven to the new guy coming in that you are incapable of recognizing a well done design, but you also tend to drive him away by forcing him to do something that runs contrary to his nature.
There are two things that are killing my productivity right now in my current job (actually, there are thousands, but I will limit this entry to the two that are giving me time to write this entry). Waiting for data to move across the network in the form of database back ups, and complete lack of standards for tracking bugs and their fixes.
I spend probably 3-4 hours a day just setting up backup databases from clients in order to reproduce/test/fix bugs they're having. Given how the system is setup, it is almost impossible to test most bugs from a simple test DB setup. The reason for this, if anyone is interested, is that we allow dynamic forms to be built, and they all behave slightly differently based upon the configuration. So, to reproduce most of these bugs, I need the specific data which triggered it. Because of HIPAA standards, though, I can't just reach over and dig through their databases. I have to request a backup from IT, which may or may not be encrypted, and load it locally to play with.
The general setup goes along these lines:
I send an email to IT requesting the backup.
I get a response from IT that it is copying to my shared folder.
The database is copied, so I take it from my share onto my local machine (SQL Server Management Studio won't browse network drives that I've found.)
Once it is local, I can restore it. Unless it is encrypted, then I have to copy it to yet another server where encryption is running.
Once it is up, I have to run multiple scripts on it to setup permissions to give myself access.
Finally, I set a permissions file for PHP to tell it where to access it.
The above takes anywhere from 30 minutes to 4 hours. Per database. It kills my productivity. I can't continue my work until I get the database, so I end up reading around on the internet a lot, which makes me feel like a slacker, which I don't like. But I've been unable to come up with a solution to the problem. I've suggested to IT to give us a server in which we can pull our own databases, where everything can be done locally without the need for copying these things all over the place.
The other speed hit is that Im running on a gigabit NIC, yet somewhere in the router chain to all of the other machines I need to copy to/from, there is a 10mbps switch, which "dumbs-down" the entire process. This too, drives me nuts.
That's one threat to my productivity. The other is how my company is tracking bugs. Right now, they're using two individual systems (they are trying to merge to one, but it's a slow process). They are using SalesForce primarily, and are currently working to prepare an installation of Sugar to use instead. The problem is, updating each entry for bug tracking is currently being done half-assed. So when I tell $boss2 that I need more work to do, she hands me a list of bugs from SalesForce, half of which are invariably already assigned to someone else, or already in QA for testing, or something. Worse, the customer service people are typically the ones opening tickets. They are in the habit of copying and pasting emails directly from clients, which forces me to do their jobs, which is actually finding out if a bug exists. The ticket should not be crossing my desk until the bug is identified and the solution decided on. Because of all of this, I spend more time trying to figure if there actually is a problem, instead of fixing them.
Once I do prepare a fix to a bug, even though we have CVS and SVN servers running, the code doesn't go into those ... it goes into an email to QA, where they do $deity-only-knows what with them. So once it leaves my computer, I never see it again until its time to roll out a release. Now, I may have my facts wrong about how CVS is supposed to work, but I was under the impression that when you check-in, you keep old versions so that each iteration can be "un-done". This would keep us from having to build whole major versions from multiple sets of code fixes each time we want to put out a patch, or make it easy to revert a change if we didn't like it. It would also ensure we have the latest bug fixes each time we pull code to work on. But like I said, I may have my facts wrong.
Im not sure how to fix these problems, as I don't have a lot of control over the process before it gets into my hands. But they frustrate the living hell out of me, and cause me to waste untold amounts of time.
It occured to me, recently, that the professors who shoved buzz-words like "re-usabilty," or "maintainability," or even [shudder] "documentation" onto us repeatedly and often in college may have been on to something. I have just up and left my home of 12 years in Lafayette, LA to take a job in Shreveport, LA where I am currently encumbered with someone else's [poorly written] code. Suddenly, things are starting to make sense in a way they couldn't have made sense before now.
I've been coding since I was 17, when I borrowed a C++ book from a co-worker and that was, as they say, that. Not long after, I set about enrolling in college (University of Louisiana at Lafayette), where I entered into an extensive study of all things mathematical. (I always found it ironic that, while I am incredibly good with programming languages and programming in general, I have never been very good at math. Especially since, when you get right down to it, computer science is just fancy math. I digress, however, as that is a topic for another blog entry.) From day one, "maintenance" was the word of the day. However, due to the nature of things at that level, most programming was a solo affair. It is incredibly easy to maintain something you have written yourself (hopefully), where you possess the "broad view," as it were. You know how the system is supposed to function (again, hopefully), and you know what each piece is supposed to do. It is easy to go into code you have written from #include
I took this job with the hope of the naive, thinking it would be a fantastic opportunity to flex my creative muscles and dig into the technology and use it to build things that I could be proud to say, "That's my work, right there." Well, I was partially correct. It has definitely been an education, but the lessons learned were not quite what I thought they were. So far, I've learned about 16 thousand ways NOT to write software. I've come across VERY few things done well, either. So, I thought I would share a couple of the lessons for the future that I've had to learn with anyone who might happen to cross my path here. A couple things that would have made my life here infinitely easier. My work right now is with PHP / MSSQL, but most of the following applies to computer coding in general.
The Art of Mis-Direction
The longer the chain of function calls I have to trace, the more annoyed I get, and the more time I waste. Functions which call other functions, temporary tables that get accessed once, temporary table chains created through 15 different functions in 15 different files all create havok in your code and are often unnecessary. Keep things simple, and keep related items close together.
Do one thing, do it well
There is an old saying, "Brevity is wit." Not sure where its from, not sure of its original context, but it applies well to coding. Considering that speed is usually our top concern with computer programs, it is often a best practice to adopt a minimalist approach to coding. Make your code do as little as possible, as clearly and simply as possible, to achieve your goal. Bloat is the #1 killer of software (listening, Micro$oft?), and is the hardest defect to fix. If you adopt a minimalist approach from the start, you save yourself many headaches down the road.
Consistency in naming
Class A has member function insert_db. Class B has member function db_insert.
$varname vs.$varName vs. $Varname vs. $VarName vs. $Var_name vs. $Var_Name vs. $var_Name vs. $var_name ....
Consistency makes everyone's life better, and I don't have to spend so much time double checking the format of the variable being used this particular time.
Class Methods
I should not have to dig through 3000 lines of code trying to take an inventory of the methods that a class exposes. Do me a favor and place a nice, simple, concise dictionary of functions / variables that are available for me to use in the comments at the top of the file. This way, i can go in and say, "Oh, it does have a SaveToDB() function, and it returns a string which will tell me the success or failure of the save." The faster I can find information, the less annoyed I am, and the faster I can get my work done.
Whitespace means something
Perhaps my #1 pet peeve when digging through someone else's code. White Space matters! It matters alot. White space is not there for the benefit of the computer / compiler / interpreter. It is there for the human. The reader of the code. (Unless you are working in Python, then the interpreter expects the whitespace). white space in a computer program is like a lack of punctuation and capitalization in english you can figure out what is being said eventually but it is annoying it makes you stop to think about the form of what you are reading instead of the content and it just plain looks ugly there are reasons we have conventions and rules it makes life easier on everyone (I *was* going to remove ALL the white space from that, but I can't bring myself to be quite that cruel.)
Comment everything
I don't know why you did something, but I can see from the code that you clearly did it on purpose. Was there something down the line that required this time code in this particular format, even though every other time code has a different format? I don't know, because you didn't leave me any clues. Documentation is not for you. Documentation is for the poor bastard who has to clean up your mess.
...
Those are the ones I can think of for this week. When I think of more, Ill add them to the list.
It has been a while since I touched HTML/CSS, as most of my time is spent debugging PHP code, and the layout is usually finished by the time it gets to me. Hell, I haven't touched any since my days at Firefly. Well, my brother and I have been talking about doing a website for him. He needs a vehicle for customers to find him, I need a vehicle for showing off my talents.
So he gets me all of his images and such, so that I can start laying it out on a web page for him, and I tear into it thinking "Man, this looks exactly like his mock-up screens, AND its easy!" Then a thought occurred to me. I have only been checking Firefox. Crap. Load up IE7, completely and totally different. IE7, apparently, does not like the use of auto-margins to center things on screen. I hate you, IE7. So Im trying to figure out how to accomplish the same affect in IE7 as auto-margins give me in FF. Time to de-rust my CSS skills.
I finally have my own blog. Yay me.
Page: 1