A great project never has a shortage of ideas. A great developer never implements half of them :)
Welp, today is my birthday and though I’m a year older and wiser (so they say) I’m excited to see what the future holds.
As I was renewing my domain, I stumbled upon a very important date - the 25th of April. Why is this significant? Because it’s the date I launched the pilot version of Simple Dental.
The idea was to get feedback as fast as possible. It worked. What followed was only a few more features developed and a whole lot of attention to what was already there. It was the project I dreamed of working on and developing for.
After about 6 months of heavy use I started inviting more people. The feedback wasn’t as well received and most of the people who did want to try it out didn’t really give it a shot, or even ask for a guide or walk thru. Inevitably I felt a little lost, concerned and burned out at that point.
I let a few months go by. I kept in contact with the clinics still using it and one of the main features it was missing was charting. I set out to do that and had a working version within 2 weeks. I was back, err so I thought.
Fast-forward yet again to now. I see that date as a huge revamp to make things even simpler. We are talking about gutting what is barely used and replacing it with, well, nothing. A few requests have come down the pipe like guest access (we have it but it needs love). A better print system that allows you to print an entire patient file and not just treatment plans. And then my favorite… redo Treatment Planning to make it easier to assign procedures to certain doctors so it’s easier for clinics to pay outside specialists that help on particular cases.
My goal is to tackle one of these by the 25th. I’d ideally love to tackle them all, and probably could. I know that it’s going to be a busy couple of weeks but I’m excited to jump back in. At the same time, simplifying things even more, working my pricing model a bit and FINALLY launching the site should start grabbing the interest of some.
That’s my plan for April.
With the recent launch of my new project, I’ve found myself definitely pining after a certain interface design that engages users into setting up battles (product vs product). In my sketches and UI prototyping (with Fireworks), it all looks good. But when it’s brought out into HTML there are just voids that were easily filled in the UI but don’t fit right in html.
I guess this is a normal process of elimination. Am I so attached to this one particular interface that I can’t part with it? No. Because if that were the case then I wouldn’t be here talking about it. Maybe I was going after a wizard-like design that steps them thru the process. As simple as it is right now, will people find it useful? Of course the answer to that is launch it and find out.
I guess I’ll just have to do that.
Lately I’ve been trying to have my own ground when it comes to what I believe in. When you are a single person on your own project it’s easy to make decisions that only you need to support. Well, that and your customers. But it’s another world when someone else is also invested in what you are doing together. It’s a big change for me and suffice to say it hasn’t been an easy road thus far.
Part of me like to hold onto what “I believe” and part of me let other pieces be decided by someone else. My main issue is I like working on new and exciting things while my partner likes to work on strategies and things that “have worked in the past”. I see we are two very different people when it comes to priorities and I’ve tried very hard to have a place for his ideas/thoughts. I’ve even spent a majority of the dev time working on tools to help him.
But when should I start standing up for what I believe in again? When can people start seeing that it’s not just about what they want, but what’s better for the project as a whole? I’m guilty of building things that don’t offer immediate value to the project just because I felt like building them. But that doesn’t mean it was a waste of time or resources. You have to keep things fun. You have to enjoy what you’re doing. Scratch that. You have to love what you do.
Well, my new project I co-developed is live. Before I ramble on too much I’ll toss the link out to those that are interested. www.tabletwars.com
The interesting part of this launch is how it’s made me feel an hour or so after being live. The first feeling I have is: was this rushed? I don’t think 3 months is considered a rush by my standards but a lot of the dev was also out of my control, being that I had a partner on this journey.
One thing is for certain: from the beginning we used version control and some sort of project managing. We questioned features before we built them and we started with simple ideas.
However, now is the time that I look over what we have and take an axe/chainsaw to features/ideas. I think this project was stuck “baking” for too long and as such has left a bitter taste in certain areas. Last minute I’ll admit was a sprint and rush. Details that were lingering were just executed instead of cut.
In the days leading up to this we’ll see what this is made of. Feel free to drop me a line with feedback on here or via email jacob (at) sadsoft (dot) com
Take care.
Source: tabletwars.com
What tells your products story is not what is in it, but rather what is not.
Recently 37 signals decided to redo their basecamp software and they cut a lot of features last minute, some features that were actually developed and working. What’s interesting to me was the decision wasn’t to cut it months earlier but rather last minute
You should be willing to accept cutting anything at any stage.
Whenever I start a new project, the first thing that comes to mind is the time required to actually get something up and going. That is to say, going for a private release party and not just yourself.
We all wish with new projects we could have a deliverable by the end of the day, or have some substanial amount done in a weeks time. But why is it that that never works? I think it has to do with the fact that we are so obsessed with delivering something so new so soon, and not caring about the details along the way.
The hardest part about project planning is to know what to cut and when to cut it. When to take out features that will take longer and when to leave them in and just hash them out and develop them. Is my quality overall going to suffer without feature xyz?
When everything in your project is based around how aware you are of your needs, it can be a tedious project to start with. It’s easy to just commit to everything and start work. It’s not as easy to hand-select a few great features, and make them even greater.
Basically time constraints are pointless and we shouldn’t dwell on the deliverables. Set a nice buffer of say a month and say I’d like to get this project to this state by this time. Now how am I going to do it? What am I going to work on today and more important, what am I going to work on tomorrow? These are the questions you should always concern yourself with. Your project and scope will change all the time. But you are in control of how much you are actually willing to commit to. You can cut a 5 month project to 2 weeks, if you want.
The deliverables — at the end of the day — are just details waiting to be hashed out. Take the time and focus on making your own development process easier.
I’ve seen so many businesses play their own misunderstood catch up to their competition when it just isn’t necessary. You can’t change what your competitor is doing, so why worry about trying to stay one step ahead of what they are doing?
If they haven’t cornered the market by now, wall-to-wall, why would you worry they will start picking away at your base and share? Unless, of course, you are not sure of your own product. In which case, well, good luck with that.
As entrepreneurs we have a responsibility to be leaders in our sector regardless of whether we want to be or not. When you take this notion of creating something instead of working on something for someone else, you have to lead that something. There is no way around that.
So chasing the competition and playing the one-upmanship is just tiresome, boring and exhausting.
Be proud and represent what you’ve created for yourself. Stand behind your product and let your customers know you do!
While it’s equally important not to dwell on one set of mockups or sketches during the idea phase. It’s also not a bad idea to keep an open mind that things are ultimately not the “final product” and can be subject to change. Don’t be afraid to change it at this phase.
It’s also equally important to note that when you are actually coding out your mockups or sketches they may appear different in a browser / real life setting (the UI people will be interacting with). Don’t be afraid to swap things around at this point as well. Don’t make drastic changes, but if something doesn’t line up the way you want it to don’t sweat it. Just change it accordingly and make sure you are satisfied with the result before moving on.
After all, it’s harder to change what we’ve completely committed to versus something we are on the fence about and haven’t fully explored/developed out.
I can’t stress enough that even your simplest ideas still need sketching / mockups to hash out what is important to you. There is no faster feedback than using the right tools to quickly explore your ideas (whether that be paper, some application, etc). It’s the inevitable step shortly after it’s entered your brain.
When you think about git repos and ticket trakcing and time management, it all sounds team based. But can it work for single dev projects? Absolutely. In fact, it’s better to have some sort of plan than to not have one at all. I mean, how are going to track changes to what you’ve done if not for some sort of versioning systems and tickets to track bugs, feature requests, etc? This is not ouside of the scope of a minimalist’s toolbox for development.
Don’t get caught up thinking you are doing too much by having some orginization in your project. Just find a tool that doesn’t take you months and months to set up for a single project. Find something that is fast, easy to update, and most of all, helps you organize and track the progress of your project without sacrificing tons of precious dev time.
In closing: Use Git or SVN or any other versioning system, even if you are a single dev. It has a little learning curve, much like anything you start out, but it will save you so many headaches being able to see when changes were made, to what files, etc. I can’t stress how invaluable that sort of feedback is with my own projects.
Cheers