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
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
Posted by David Harris
Sun, 30 Jul 2006 19:44:40 GMT
Ok, so first of all I’m sorry I dropped the ball on the Fictiverse series. It was probably a bad idea to start those at the same time as my job was picking up AND I was working on my own Rails apps. Hopefully I can get back into those in the next month.
Currently, I’m knee-deep in Rails junk, and realizing that the shiny goodness of Rails goes away when you get farther into application development. However, that’s where the clever right-brained Ruby language picks up and leaves you able to program without getting burned out. However, having a 40-hr/week job using C# plus trying to develop in Rails at home gets a little tiring, and it’s taking me a lot of effort to complete my first app.
However, much of my pain may be alleviated thanks to the guys at RightCart. I recently received an email asking for feedback on the cart. Now, as cool as the app was, I didn’t have much use for it. I have no products to sell or ship, and even with the latest improvement to allow digital content purchasing (like ebooks or mp3s) I had little use. I don’t sell things off my blogs, except if you want to buy my eternal love and gratitude, linked on the previous post. :)
But, while doing my own apps and some for a friend, I ran into a real problem… how do I actually accept money for this? Now, I know the basics, having set up shopping cart systems for people using open source stuff like Comersus or such. I know about merchant accounts, etc., but my real problem is that I didn’t want to spend time to find the perfect payment gateway that was easy to use but also allowed recurring payments (for monthly subscription models), etc.
How nice would it be just to drop in two lines of code, and have a cart that automatically handled your subscriptions? I’ll tell you: it’d be awesome. I was looking to use Google Payment (because let’s face it, if they wanted to buy me out I’d flip it in a heartbeat, and they’d have an easier time with it). In fact, I was set on making a whole Rails plugin just to handle this, so other people could have less pain. Programming a cart is not really fun, and I’d rather be focusing my efforts on my application, not how I get the few bucks I gain from it.
So when RightCart requested feedback, I probably annoyed them with two incredibly-long emails. After all, subscriptions are just products I can set up in my right cart, and now they even allow recurring payments! However, there is no pingback to me when an order is made, thus I cannot update my database to allow the user a subscription. So I emailed them my suggestions, as newbie as they might seem, basically requesting that I provide a server address they can ping with an order number, such as http://application.net/orders/10200394. I then take that number, check the RightCart xml feed, and update the order as appropriate. And with the new ability to include “special information”, I can capture the “add to cart” click, record the user’s information, create a hash in the DB, and then check the order information against those hashes. Basically, everything I need with one simple mod, and plus it allows for power users to ping their own website so they can use a custom order/inventory system.
Now, I’m not saying it will always work for me. If an application grows to gargantuan sizes, I might consider writing a custom cart/checkout and get a real merchant account. But at 1% cost with RightCart, you can’t beat that. In fact I don’t know how they do it for that cheap. It’s absolutely perfect for small starter sites. How many out there have spent about half the total development time handling how to get money? How much time would RightCart save us by handling that for us? Plus, it abstracts that part from my application, and frees me from the worry I’ve implemented something that could potentially screw with my users? Or worse, with my income?
I’d like to thank Ryan Garver, CTO of RightCart for taking the time to listen and respond to my needs, and I fully support the company, and can’t wait to use them for all my applications! They have an incredibly responsive team, and I wish them the best. I hope the mods I suggested can propel them even further. After all, they are about to make my life incredibly easier, so why would I not promote them to my best? And for you developers out there, check the app out, it will save you much time and heartache. :)
Posted in Programming | Tags rails, rightcart | no comments | no trackbacks
Posted by David Harris
Mon, 20 Feb 2006 20:31:00 GMT
On the recent SvN blog by 37signals, I was a little perturbed by the people posting comments there.
I thought by now people would be embracing agile standards, less software, and good design principles for maintainability. But apparently some people are lost in wading through the older school of thought that more features makes a better application.
And sometimes, more features do make a better application, if and only if the application cannot survive without those features, or it would diminish the ability for the user to operate the software.
Especially on the web, less is more. There are millions of applications out there, and you are not going to make your mark with the application that does everything. The way you survive, and even thrive, is by making a great application that does one thing perfectly, and paying attention to how your users are using it.
The most valuable thing I have learned is that you cannot use agile methods by asking the user what he needs. Why? It’s very simple: the user doesn’t know what he really needs. The user DOES know what he has seen elsewhere, and will always ask for those sort of features. But what they really need is not those features, but it may be a completely different feature that does a better job than the one he thought of.
The way to go about that is not asking your users what they need, it’s to listen to their complaints, consider what everybody is saying, and find a way that solves it creatively and in a better way than they are asking. If people are asking for timestamps down to the microsecond, why are they asking for that? Well, in the end it may be just to uniquely identify each record to point it out to others. Yet this same problem can be solved in less code with simply adding an anchor to each post and providing a hyperlink generator. Or perhaps you can “tag” a record a certain way, and let people look for the tags. Or maybe clicking a record highlights it, which not only saves your favorites, but also could provide a way to see what you deem as important.
Obviously it doesn’t stop there. In web software, we have to figure out a way to keep feature creep out. The best way I know of is to just say no. Develop a list of boundaries for your software, and adhere to them. Define what your software will and won’t do at time of release, and only deviate in extreme cases or when you think the product will actually benefit. Users eventually dictate the course of a product, but in the end the developer is the artist. As a musician, do I make music for other people, or myself? Only the former if I’m a sellout. I can make a lot of profit and have a gargantuan behemoth of a Web 2.0 taggable application that really just sucks the life out of me. And where is the programming joy in that?! Give me something I love to work on any day over an application that fills every need a user might or might not have. In the end, my ability to fix the application is more important than the trends and whims of my users.
Posted in Programming, Thoughts | 1 comment | no trackbacks
Posted by David Harris
Tue, 13 Dec 2005 18:56:30 GMT
This will be the first of several project introductions, in an attempt to have a foundation for each thing in writing.
Novelpad is a project I thought of about 2 years ago, and bought the domain www.novelpad.com. Originally, the plan was to create a program in C#.NET that sorted a novel into arbitrary sections (such as Parts, Chapters, Sections, or Acts, Sections, etc.) such that it could be used for any project type, a novel, screenplay, etc. However, the more I designed how it would look and function, the more complex it became. At that point in my life, I became enthralled by the Less Software mantra and scratched the whole complex idea, which had about 2000 lines of code already written just for basic stuff.
Enter my love for Ruby on Rails, the platform I’ve discussed here and there. The answer was not to figure out a way to release software that could be bought, but to provide a monthly service at free and paid levels. Instead of figuring out how to get a bunch of large one-time payments, I merely needed a way to provide a software that so helped a novelist’s work that he would be willing to pay a few bucks per month or quarter. This would not only be cheaper on the end-user by allowing me to work on updates and improvements, but it would be a much more budgetable way for me to sustain some sort of income from the project.
So, now the idea has changed. The basic concept is simple. The interface will look like Word, only with basic formatting tools, things you would see in novels. On the left side will be a treeview of blocks that can be arranged as desired, each given a name and a description. These blocks can be moved in and out, such that a chapter becomes a Part, a Section becomes a Chapter, etc. Each block, when moved, will rearrange the final output of the novel. When clicked, the block will open up the text on the right side, where it can be edited and formatted.
That allows for the data of the novel, how it is arranged and what it contains. Next, I will provide a complete formatting section for describing how the hierarchy of the blocks of text will correspond to the final look of the novel. For example, some books have a little ” . . .” separating the sections. Or perhaps they have a funky design surrounding each chapter number. The formatting section will describe how this should be done. Also, it will allow for chapters having names displayed or not, should the chapter number be on its own page, etc.
Finally comes the publishing section. This takes your novel, combines it with the formatting, and exports a full PDF or Word file of your novel, ready for printing, each stamped with your copyright details. It auto-generates a table of contents and/or an index, and will even provide the writer statistics about word usage (i.e. “you used the word ‘exclaimed’ 2236 times” such that he can make edits right away. It will also be able to automatically generate an outline from the block arrangements and description.
Basically, this tool will solve the problem many people have with actually producing their own novel. Microsoft Word sometimes makes things so difficult that people get caught figuring out how to format something, and it steals time they could be writing.
Additional features not yet planned initially would be character databases to store your characters and their information, timeline managers to help preplan a novel and auto-generate the blocks needed, research help such as a thesaurus and atlas and stuff like that, etc.
So there explaines Novelpad, probably one of the middle priority items to develop.
Posted in Programming | 1 comment | no trackbacks
