The time taken to fill the form is dominated by the time it takes a user to understand the field label and fill the input box. I think UX people use the term 'cognitive load' to describe the effort taken to understand. This paper presents research that shows that vertically aligned labels cause less cognitive load on users, resulting in faster form entry:
http://www.uxmatters.com/mt/archives/2006/07/label-placement...
In order of decreasing importance, I recommend you: Constantly check that you're building the right thing. Get some kind of testing framework. Look into Test Driven Development as a methodology.
With a testing framework, you won't waste time rolling your own. For Java, you could start with JUnit.
TDD is a formalized approach to writing test functions as you work, which you already do, while simultaneously designing your code. There are many sources on it around the internet, but Kent Beck's book took the magic out of it (a good thing) for me:
http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0...
Of course, there are many other specific techniques you can use to test that your algorithms do the right thing, all dependent on what you've made. Regardless, I try to make sure that the a real user gets their hands on an up to date build as often as possible, and they're sure to show me all of the ways that my software is technically excellent, yet in no way solves their actual problem.
Also, please check out 'Behavior Driven Development's or BDD, which is basically "TDD done correctly." It alters the description of the process a bit, and in the end, you write better tests.
Since I'm a Rubyist, I use Cucumber and RSpec to do testing. http://cukes.infohttp://rspec.info (note that you can use cucumber to test any language, and I bet you could use JRuby to test java.
But really, conceptually, BDD isn't that complicated. The hardest bit is figuring out the tooling for whatever language you're using, getting comfortable with it, and practicing. I know the Ruby side of this well, but if you're using another language, I'm not sure I can be of much help.
Adding on to your comment, a friend let me read through a beta copy of The Rspec Book last year. At the time, only the first couple chapters were written and it was lacking a lot of content. It was a great resource though, and I would highly recommend it. The final release is due "Soon", and ordering it now gives you access to the current revision of the Beta, which I hear is complete sans-editing. I'm holding out until I can buy a paper copy.
These are all Ruby or Rails specific. Cucumber itself is a DSL to be used along with another language, and there are projects underway to implement Cucumber or Cucumber-like frameworks for other languages like Python, Java and .NET
Thanks. I almost linked to the RSpec Book, but since I haven't read it myself, I didn't feel comfortable endorsing it. Good to know it's shaping up! Maybe I'll have to pick up a copy.
While it's not what you're asking for, you might be interested in Robocode: http://robocode.sourceforge.net/ It has been around long enough to be 'balanced', and even the most advanced strategies are documented by the community and available for you to improve upon. The community has also developed a way for people to submit their robots and have them run against all of the other robots via a distributed tournament client.
The description, from the website: "Robocode is a programming game, where the goal is to develop a robot battle tank to battle against other tanks in Java or .NET. The robot battles are running in real-time and on-screen."
Are you going to also follow his advice and hire two or three different people to work on the the first bit of the project?
I think it's an interesting idea; it acknowledges how likely it is for a software project to fail, or to at least be mediocre. I've always wondered whether large companies might be able to do well with several teams working on the same projects, and a process where one team's code is periodically selected to form the basis of the next version, then everyone else starts from there.
You will always be able to come up with reasons not to take risks, and they don't have to be particularly good ones as long as they give you an excuse to wait a little longer. There will never be a right moment. I recommend you evaluate whether you're happy with your current situation, and if not, then seek to change it. Your choice isn't simply between keeping the job and quitting it; perhaps you can find a different way.
I was in a similar situation as you are; running a small programming team at age 27, with no real commitments. I decided to stay because the opportunity seemed too good to pass up, but I'll never know where I'd be now if I took a risk back then. Over those three years it seemed like everyone I interviewed ran their own project. Many popped back and forth between working as part of a team, and running teams several times in their career, so it's not as special an accomplishment as I'd thought at the time. Now it's three years later, and I've gone part time and started telecommuting so that I can travel wherever I want and have time to figure out what I want to do next. Your choices may vary. Good luck!
Actually you cannot travel "wherever [you] want", because in most countries you also need a work visa to telecommute. That's particularly the case in the US.
If you scroll to the bottom of the very long Experts Exchange page, the question and answers are down there. While I realize your question was meant to be rhetorical, EE has answered my question a few times, and I want to say that they do provide some value, which I suppose is reflected in its page rank.
Yeah, I realize if you scroll all the way to the bottom and ignore all of the up-selling of premium access, you can see the real answer, but their pages are designed specifically so that you don't notice this and don't bother to scroll so far. I just use Experts Exchange as an example because they seem to be another company that uses SEO gaming techniques to get a PageRank that isn't really justified based on their content.
I'll admit, I have gotten an answer or two from EE, but at the same time I also wonder where they stole the real content from. These companies that do SEO rarely generate any real content themselves. They all violate copyright in flagrant ways.
He ended up creating his own build system, "tup" < http://gittup.org/tup/ >, based off of it. It also has the property desired in this article that, "No-op builds should be O(1) and instantaneous, and most other builds should be O(WhateverChanged)".
The graph in page 25 is thought-provoking (tup-vs-make on a change-one-of-N files test, N = 1 to 100k).
Interesting quote: When a single C file is changed in
the 100,000 file case, make can take over half an hour to figure out which file needs to be compiled and linked.
The first diagram in the paper is the commonly implemented version of waterfall. Dr. Royce didn't intend for it to become so, however: "I believe in this concept, but the implementation described above is risky and invites failure."
He goes on to explain what else is required to do it correctly.
