On Pushy Projects and Programming

Time for a “misguided projects” rant – better buckle up, it’s going to be all over the place.

We’ve all been there – working happily away on our project with the timelines in place, thinking that things are going to be just fine and dandy. Then, the malevolent spirit of feature creep (let’s call him Steve) comes in, sneaks into the safety that is your cube, and shakes things up a bit. Steve’s only goal is to come in and make you freak out. No, Steve doesn’t have to be a person, but he’s all too real for too many developers out there. They come into the project, look over the spec, and think to themselves “this doesn’t look so bad…I can just use this here and that there”. They place the sheet back on the table, look around at all of the other happy faces and think maybe, just maybe, this time things will be different.

Well, not if Steve has anything to say about it. No, I’m not talking about a specific situation here – I’m just blowing off some steam. Between dealing with other companies/other developers that just don’t understand your deadlines and having a Steve on your back, development just isn’t something to be taken lightly.

Have you ever started working on something, gotten about 30 minutes to an hour into it and realised that there was a much better way to do it? Sure, some people immediately jump to the “well, you should have planned more” argument, but sometimes, that’s just not good enough. There’s those out there that will tell you that there’s only “One Best Way” to do things when it comes to web programming (or just programming in general). So, who else out there wants to help me prove them wrong? Sure, there are best practices and all, but that doesn’t mean that there’s no room for flexibility. Too many developers are loosing that touch, it seems – they look at code, see that it’s a pretty dang good way to do things, and just keep using it over and over until something better comes along. Does this mean that you should rework every bit of code that you come across to make it better? Of course, not – that can only lead to a wee bit of insanity (and possibly a visit from Steve).

Instead, look at what you’re working with – whether it’s your own code or someone elses, and see if there are any glaring mistakes. Unfortunately, a lot of the PHP code that’s out on the repositories (save the stuff that people charge for…well, okay, some of that too) is “newbie code”. Not all of them are new to the language, but unless you get a little further on in development years, there’s just some things that you miss. No, I don’t have a particular list in mind of “Top 10 Newbie PHP Mistakes” (maybe I should make one), but most of the more seasoned developers out there know what I mean.

Maybe we should start a list in the comments….hmm….any takers?

*whew* okay – that’s enough for now. Sorry for my meandering mind, it takes me for rides too sometimes. Anyway, if you have any comments or want to contribute to the “Top 10” idea, leave some comments below…

7 comments

Ah, I know Steve well. 🙂 I often start PHP software projects on the side that I envision I could release at some point, but I always end up coding “too soon” without planning just how I’m going to architect the darn thing. Then I get all these ideas for new features, how to re-do old ones, etc. Pretty soon I end up with a mess of code that does 30% of what I want and its hard to change.

The latest project I’m working on I’m doing differently. First, I’m basically laying out in a digram (pseudo-UML) all of the classes, workflows, etc. I don’t code until I know exactly what I’m supposed to code. I’m using PHP 5 and the latest OOP design patterns. I’m using abstract classes and interfaces so various objects are de-coupled and can easily be replaced. I’m also using some PEAR classes to provide low-level services (I don’t need to reinvent the wheel!).

So far, it’s working out very well, and it’s actually taking less time to get more done. I think a lot of PHP “newbies” would be better served learning less about PHP and more about good software design to start with. I know it’s tempting to jump into code right off the bat, but after a while you end up realizing you need some technique or you’re going to end up with a mess on your hands.

Great site/blog BTW. Keep it up!

Jared

LikeLike

“So, who else out there wants to help me prove them wrong?”
I’m doing my best already, E. Glad to see I’m not the only one.

LikeLike

The story sounds familiar. As soon as someone starts touching the requirements, it’s easy to lose focus. That’s why a lot of literature stress on the fact that you should stick to the requirements, no more, no less. Also, it’s good to define _who_ is messing with the requirements. If it’s a co-worker, tell him to stop guessing at what the client might want; if it’s your boss, try explaining him that feature creep makes it hard for you to keep concentrated on the projects’ main goals; if it’s the client, investigate how many hours it will take you to make the desired changes, and see if it fits in the budget. Either way, customer is king. What helps in situations like this is to define what your core goals are by designing use case diagrams and write out accompanying use cases. This way you can make sure everyone on the project knows what the focus is.
And yes, I agree that there is no single best way. There are always multiple solutions to a problem. However, if you do stick to “best practices” (e.g. design patterns) to solve problems, it might make it easier for others to understand your code, because they have your approach “labelled” in their problem solving catalog. Definitely don’t rework stuff if no change is needed now or in the near future. Programming is hard – you need to be adaptive and stubborn at the same time. When people just start programming, they find it hard to interprete coding styles that differ from their own style. There’s a good solution to this: practice. Read a lot of code, try to understand it, modify it in its own style. That’s how you learn. Opensource gives you that chance. And yes, every programmer will have to deal with ugly code sooner or later. Here are some of my “favorite” newbie PHP mistakes:
1) topdown code (no structure, no abstraction, and much repetition and conditionals)
2) no input filtering (we all know it by now)
3) one-environment-only code (magic quotes gpc, using static paths et al)
4) reinventing the wheel (mktime() is often forgotten..)
5) unreadable multidimensional arrays (with all too often numeric keys to obfuscate even more)
6) sending HTTP Location header calls without calling exit() (and code executing after that..)
7) leaving display_errors on on the server (with ugly warnings etc. in case of unpredictable errors and what not)
8) classes that do it all (improper OO design, if any)
9) insane function and variable naming
10) scripts that solve problems that should not be solved by using PHP

Whew. The order doesn’t necessarily represent my personal order of “favoritism”, but those 10 things immediately jump to mind when I’d have to make such a list. I’m sure others can contribute great additions to it.

As a final note: keep refactoring! When adding features, _always_ consider the overall design when you’re making them. Don’t just add features. Don’t clutter, write beautiful code 🙂

LikeLike

Hint to commenters: be careful with the top-10 comments. Be ‘gentle’. Scaring off newbies by putting them in a ‘you suck because..’ corner would be a waste of this blog. Try to teach, instead of criticize.

That said, one of the things I’ve noticed a lot in ‘newbie’ code is the desire to copy/paste a lot. (“Ah, this 10 lines of code do the job here, let’s just use them over there too”). Functional Decomposition and Refactoring are good principles to learn right from the start. It would be a bit lengthy to explain these two concepts here, so I’m thinking about writing a short article on functional decomposition later this week.

LikeLike