Posted by David Harris
Thu, 30 Nov 2006 20:29:00 GMT
I’ve not been a developer for a long time, but I’ve been around just long enough already to learn the lifecycle of a “real world” project. Note that this is for single-developer projects. Team projects give you a lot more latitude and ability to make these things work more seamlessly. Sometimes.
Phase 1: Planning
Most projects at least, thankfully, begin with planning. It’s almost never enough, and rarely covers all the special cases you’ll later be coding late nights to fix. But there is still almost always a phase where you at least are given a set of features, maybe a basic UI desire, and a pat on the back. As the developer, you get hard to work designing the perfect database structure, thinking of clever ways to organize code, until a day or two later in…
Phase 2: “Git ‘r Done!”
This is the point where you have things about half organized in your brain, and then get told “We needed that yesterday!” And, the corollary, “Get it done, it doesn’t have to be perfect!” And it’s not perfect, not the shining gem you hoped to produce, but it works. It works for every case they gave you, and when you’re finished you sit back, hoping that’s all they want. But it never is…
Phase 3: “But see, there’s one exception…”
In this phase, you realize what they told you in phase 1, and which you used to shortcut code in phase 2, did not line up with reality. For example, they say “All employees come in at 8am and leave at 5am.” So when you’re rushing for release, you make that an assumption. Phase 3 is where they come in and say “Well, we have this one employee, Bill, who comes in at 10am and leaves at 3pm”. For a minute, you think you might can get away with coding that one special case in. Until you realize that later they’ll have yet another exception to cover. So you rewrite most of the business logic and make a few database schema changes. And in the end, you wind up with better code anyway, and start to feel good about what you’ve produced. Until the inevitable…
Phase 4: “I’m a creep, I’m a weirdo. What the hell am I doing here?”
Of course, we’re talking about the inevitable and dreaded Feature Creep. For months, maybe years, you add feature after requested feature to that nice little software package. Maybe it began as a simple timesheet application, but now it’s a fully functional document repository with full search and indexing capabilities. We’ve all been there. Thankfully, the end seems to be in sight when…
Phase 5: “We had to let Bill go…”
They make a policy change that renders that previous Phase 3 exception void. Maybe all employees are forced to get there at 8am. Maybe they fire the guy who keeps coming in late. Either way, they no longer need your clever system for time configuration, as it adds a slight bit of complexity they get no benefit from. Only now, the whole system hinges ever so slightly on that one bit of business logic, you know that if you even touch that code the whole mountain will topple. So you finally stand up for yourself and say “no!” And then you quickly come back with “Well, it would be possible if we did a…”
Phase 6: Rewrite.
Inevitably, your code will reach a point where you just need to rewrite it from the ground up. If you had known they wanted a document repository from the beginning, you would have designed it in. This phase gives you the chance to really plan things out knowing everything that should be included. So you work and work and release a final version that does everything right, only to find out that…
They hired Bill’s son, who works Bill’s old schedule.
And the cycle thus repeats itself.
Posted in Programming | Tags boredom, development, lifecycle, software | no comments | no trackbacks
Posted by David Harris
Mon, 13 Nov 2006 21:54:00 GMT
This is a sponsored post for Reviewme.com:
Somewhere in the midst of today’s feeds I ran across the site reviewme.com. After seeing what it was about, I was surprised to see that googling for a minute gave no other similar services out there. In an age where the top bloggers (such as the TechCrunch and Engadget tier) get free PSPs to test out and review, I was shocked to see that nobody else had already capitalized on this yet! Correct me if you’re able to find another place. So props to these folks.
(Edit: I have since found a similar service)
The basic premise is simple—companies want to advertise, bloggers want to defray server costs. I once read that a corporation spends on average $100 for each customer they get, in terms of marketing and advertising costs. So, with a service like reviewme, assuming a review gets only one customer (and not several), businesses essentially save money by using this instead of traditional methods. Plus, it tends to promote an image of being culturally relevant; the product or service gets into the blogosphere, and we all know that never hurts.
For the blogger, it makes sense, because it might eventually get rid of all ads. As much as I like Google’s Adsense, I don’t yet get enough to defray the cost of renting a server. Granted, I’m not a Michael Arrington, but still, one of these reviews per month gets me what Google does, with more whitespace around and slightly less of a load time.
For the reader, it makes sense, because you’re alerted to a product or service you might otherwise had not known about. Reviews are impartial and biased only to the feelings of the blogger, so if you trust your rss subscriptions, you can trust the reviews. Some people believe this system isn’t as ethical as ads, but they do come with a disclaimer of being a sponsored post, so I don’t see any major ethical faux-pas. I think if your readership dislikes them, the blogger should probably not go that route, but these days most readers understand the need for an advert placed somewhere, so this will probably catch on too. Bloggers can accept or refuse offers, so if they don’t want to review Viagra, they don’t have to. And at the least, it keeps new content up on the site. On a slow news day, why not put a nice review up?
The main thing I love about it is that for once, it allows the small-medium sized blogs to actually succeed. Where large blogs get plenty of revenue, they might have to post 2-3 times per month to make the same revenue they get from a strategically-placed google ad. A small blog can post one per month and equal that amount, and still be a good benefit to the company being reviewed. At least, I hope companies won’t only go for the large blogs and ignore the untapped small to medium market.
So thus far, I give reviewme.com a good chance of succeeding. They basically seem to split costs halfway with the bloggers, so it’s much more fair than most advertising systems. I only hope, as with all systems, that it doesn’t get abused somehow. For now, it definitely seems to make a blogger’s life easier.
Tags advertising, blogging, reviews | no comments | no trackbacks
Posted by David Harris
Tue, 07 Nov 2006 05:36:06 GMT
Ok, I’ve always had this theory about music, particularly the structure behind music as a whole. Obviously, most music genres are simply a fork of an older genre. For example, we know country music is the uncle of rap music. Blues led to country and R&B, R&B leading to rap.
I’ve always thought this could be easily represented by using Graph Theory. Each genre gets its own vertex, with each edge representing how close or distant each genre is to another.
My next idea is to actually plot the whole history of music using graph theory.
My problem is I don’t know a heck of a lot about graph theory outside the 4-color theory, traveling salesman, and the seven bridges problem. However, I think I can at least get something to capture data for the graph.
Obviously, music is subjective to the listener. So I think I will devise a certain way to gather the data via social networking. Obviously, that’s the best way to get data these days.
So I’m proposing a game, similar to the old Hot or Not (or maybe that’s still around). A user gets two songs at random, and must rate 1-10 how much they correlate with each other. I think from that I should easily be able to calculate edge distance, or how well genres in general correlate to each other.
If such a graph were available, and then colored by historical era, it would be easy to spot musical trends, almost to a point where one could predict which genres will be reinvented a decade from now, and which will be abandoned temporarily.
My only problem is finding a source for such songs, and having them be accurately mapped to a correct genre.
The other problem is that the set of genres allowed in current ID3 tags (and picked up by iTunes, CDDB, etc.) is very limited for this purpose. And I want sub-sub genres involved in this, like acid jazz or reggaeton or otherwise. I’m thinking I can devise a way to collect that data from the social network too.
The benefits of this are awesome, even though it’s going to take a bit of work. Imagine an algorithm that can accurately predict what a user will like given a single correct statement up front, with given probabilities. For example, the user can say “Coldplay is my favorite band and I enjoy Baroque music”, and an algorithm should easily traverse the graph to make the claim “there is a 72.3% chance you will also enjoy Weather Report, a Jazz Fusion artist. Click here to listen.”
Such a mathematical determination would easily trump algorithms used by Last.FM and other networks to choose favorite songs based on what everybody listens to. Those are good at what they do, but it’s not very good about predicting a new emerging artist’s fan base.
At the least, it will be cool to have a graph detailing the relationships between music genres. We already know Acid Jazz is a mixture between dance/electronica and jazz, but not to what degree they are related.
Sounds like a good CS senior project, if I can delay it that long.
Posted in Programming, Thoughts, Random | no comments | no trackbacks
