Looks like Google Wave is doing something very similar. What do I do?
- Continue or stop developing Mootka?
- Develop Mootka as Wave extension or as standalone application?
- Develop as I envisioned regardless of Wave or adapt because of Wave?
I have chosen to use CakePHP (an MVC framework) on the advice of Aaron. His advice:
You should ensure some sort of standardized plugin architecture is built into core of the script which would allow ‘extensions’ to be added without modifying the core. Creating such an infrastructure in code is not the easiest thing to do (lots of overhead like in writing lots of code that does not do anything directly and documentation on how to use it) and needs a fair bit of planning. Without it, after adding an extension it will be hard to change/remove without breaking things, somewhat like grafting on a finger rather than putting in a hubcap. The extensions will be prone to becoming a mishmash when there are multiple developers who are not working together.
Frameworks are great for such projects since they usually enforce a specific architectural pattern which makes it easier to build and add new components by providing built-in access points to data, functional code and for output control.
My new development method is working very well.
For each version I develop a model. This describes how the application should look and work once the version is built. I can continue to perfect it without interfering with development.
I develop the model project by project. Each project adds or improves a feature or, in some cases, more than one feature.
There have been 3 projects this month:
- 001 – Build A Tiny Bulletin Board – $550 – SZ
- 002 – Changes to Small Application – $100 – GS
- 003 – Improve Search – $80 – GS
Typically, I return in the evening and test the whole application including new work.
I record everything:
Developing a flow diagram for Project 001 turned out to be excellent way to explain unfamiliar functionality:
I am deliberately trying to chop and change the developers I employ. Benefits include:
- Less reliance on any one developer
- Can optimize developer skills and price by job
- More likely to spot the bad apple early (peer review)
- Clear end to projects
Bidding tips:
- Make it ‘featured’ if it is a big job
- Make a short list of developers (based on price, ability, integrity, ease of communication, accountability)
- Reply to everyone and explain your decisions
- Tell everyone when you will make your decision and stick to it
- Look for emails that are well written (well written emails is more liklely to mean well written code)
Sample proposal:
The job is to make some changes to a small bulletin board application.
The application URL is Mootka.com.
SKILLS REQUIRED:
CakePHP, PHP 5.1, MySQL 4.1, CSS, HTML
OTHER STUFF:
I have described [changes to] the application using HTML templates [and a flow diagram].
I will help test the application (evenings after work).
I am available via email or telephone.
I will need you to update the application online.
Your code must be fully commented.
You must be willing to fix any bugs with your code.
On completion please supply a copy of the code prepared for localhost.
You must be ready to start immediately.JOB LIST:
1. Add .bold {font-weight: bold;} to style sheet in order to stlye account holder username in main menu.
2. Change layout of main menu and link My Profile to account holder profile.
3. Link all usernames to user profiles.
4. Add <p>Last logged IN: [DTG]</p> to My contacts list items.
5. Add Description field to Profile and corresponding field in Profile Editor.
6. Add Description field to Thread and corresponding field in Topic Editor
7. Add an About page.
8. Ensure matching words in Results are highlighted as per design.
9. Ensure all notifications in right place and that notification meaning, gramma and punctuation is correct.
10. Ensure appearance (i.e. style) matches the design exactly.
11. Make the radio button for topics on the search form selected by default.
Development tips:
- Do not change the goal posts. It is unfair and will dishearten your developer. Keep a list of things you want to change for the next project.
- Build your application bit by bit. Do not give your developer indegestion. Lots of small projects is better than a few big ones.
- Develop a list of tests. Use the last test you did as the template for the next test. This way your tests get more thorough and you can confirm the issues from the previous test were resolved.
- Give the developer only the failed tests. Developers are busy and this saves them time looking through whole list of tests.
- For a failed test, say what you were Not Expecting and what you were Expecting. What is obvious to you is not always obvious to the developer.
Spotting Look2Look look-alikes all over the place now. None have cornered the market. Judging by the increasingly imaginative marketing campaigns, people still believe that the problem is one of critical mass. For example, one start up called Placeconnect offered to share 50% of its value with its first 1m users. I switched to Mootka from Look2Look because I think it is about offering more. Look2Look was like building a classified ads site (such as Gumtree) with only one category available (Missed Connections). Mootka is an attempt to apply the search-on-search technique in a more general purpose way.