We'll look at the new version of SeedCode Calendar and a number of forks in the road to debate the road chosen in both UI and scripting. This is the "no graph" calendar we worked on at Pause NYC and this session will be more about "design" than the raw "get it faster" stuff we were testing in NY.
Change in topic.
A little change of direction here: I've been talking about the new calendar a lot lately and wanted to do something that I'm a little more unsure of. (If folks really want to go deep into the calendar there is a lot of stuff online already here: http://www.seedcode.com/next and I've just uploaded an unlocked build in the comments below. )
New topic.
What I'd really like to talk about is the difficulty of managing FileMaker developers--be they subcontractors, employees, or vendor--in the context of consulting work & custom software.
This is something I am NO good at, but something I would definitely like to explore.
The format.
Below, I've proposed 8 "blockers" that, if true, seem to reinforce my skepticism that you can really share FileMaker development: that anything bigger than "one developer - one project - start to finish" starts to break down pretty quickly.
We'll talk about each, maybe add a few, and see if these are either untrue, or unimportant. I suspect they are neither. Needless to say I hope to be listening more than talking. If you have a dog in this fight, please come and share your thoughts.
- John
1. We have no accurate way to quantify the productivity of a developer.
2. Yet we have a gut sense for "productivity" and the productivity of individual developers differs greatly, often by an order of magnitude.
3. FileMaker code is not legos, and no mater how adept we may be at making things discrete and reusable, the stuff just doesn't plug and play.
4. We can't run someone's code through a spell checker, and we can't look at the code and know what it does.
5. "In any sufficiently powerful system, failure is undetectable" _ John Gall
6. "The key problem with software methodologies [Agile, etc.] is that, implemented by smart people, the kind of people who invent methodologies, they work. Implemented by shrubs, who will not do anything more than follow the instructions they were give, they won't work." _ Joel Spolsky
And when you see a software project that did work, was the methodology the factor, or was there just one, really productive, brilliant programmer at work.
7. "It may well turn out that one of the most important effects of open source's success will be to teach us that play is the most economically efficient mode of creative work." _ Eric S. Raymond Can you have a consulting business that is mostly play?
8. Many of these problems were already fully articulated in the late 1960s.
Comments (4)
Oreste Schiavone said
at 12:52 am on Apr 11, 2010
Had to split comment they are in reverse order.
Oreste Schiavone said
at 12:51 am on Apr 11, 2010
The issue is then how do I communicate with another developer. Right now I use SeedCodes calendar and FM Search results. I can't claim I understand them completely. Understanding FMsearch results helped me understand Seedcode cal but there is still a lot of work to really get deep into it. I am still dependent on emails and forums to solve some problems.
I would like to propose a developer "Resume" of sorts. Lets say a clients wants to hire me. I give them a list of clients and references that I have worked for. Then they make a decision on that. Now if I was being hired as a developer my resume with a list of clients is pretty meaningless. YOU as developers would want to know my specific skill set and how it would fit in to yours. If you pass script parameters using a XML approach and such. When I use a product from another developer I have no idea how it works. I am hiring John Sindelar to make a calendar for me. It costs $200. How does it work, I have no idea. As a developer we need to see each others "Resumes" in order to work together. We don't need to all be on the same page, that most likely will not happen. Rather I suggest, that I need to see what page YOU are on. If you have a product, can you provide your resume to other developers?
Does this make sense.
Oreste
www.kaostikastudios.fm
Oreste Schiavone said
at 12:51 am on Apr 11, 2010
After watching the video "Sharing the Work" I got the following.
1) There are no standards for Filemaker developers because there is no standard background.
2) There is no way to communicate between Filemaker Developers due to the lack of standards.
3) There is a growing trend to create standards.
4) Filemaker code is some what opaque and stylized.
One of the issues I have with the creating of standards is that I don't want to follow them. I like mine and I creative enough to make my own. Also, the standard does not take into account the "ecosystem" that standard is in. For instance I use XML like structure to pass multiple script parameters. I also use XML like structure in Variables and and other place in the database. If for what ever reason YOU don't use XML in script parameters, lets say you set variables, Then all all my other techniques get weaker. My method requires 2 custom functions that I call to pass the parameters and I use these same to and all the methods for setting variables and getting information from related tables.
John Sindelar said
at 2:55 pm on Jan 19, 2010
For those who want to take a look under the hood of the new calendar, we've uploaded an early but solid build of our free version here:
http://www.seedcode.com/calendar/poe/SeedCodeCalendarFree.zip
This is the "no graph" calendar we worked on at Pause NYC and demonstrates the global variable based approach to display we're using in the Pro calendars. Tear into it, use it in your own work, etc. Enjoy!
You don't have permission to comment on this page.