New Development vs. Phase II or Maintenance

New development

The majority of the client work we do is new development. New development is when a client does not have a FileMaker database (or has a very old database that does not fit their process) so we create them a solution from scratch. The process for that is outlined in this article, so I’m not going to detail that. The bottom line is that we start in a sandbox and we build them a castle of some sort. We start with discussing the possibilities,  we plan, we create mind maps, mockups, all good, creative stuff that has tangible results. The client is super-excited, they come up with a long laundry list of requests that we sift through and  narrow down until we establish what will be in Phase I. Everyone loves you, the boss, the secretary, even the boss’ wife. You get taken out for lunch, they talk to you often, with a lot of excitement in their voice. You are their hero. You are the person who will bring them to the 21st Century, you are Superman who can fly across the sky and can’t do wrong. And you can’t do wrong. You give them what they need, if you can guide them well, as opposed to what they might want. The only tiny thing that can cloud the whole process is that they actually will have to pay for the work, but since they have realistic expectations of what they are getting, that’s not really an issue. Very few clients actually bargain once they get a proposal, because by then they have an approximate idea of how much Phase I will cost and what they will be getting for that money. Now, all we have is the anticipation and the development work. Ad if we did our job well, the client is extremely happy with the result of our hard work (which they don’t see, of course, but everyone knows Rome wasn’t built in a day and you have to move a lot of bricks to get anything erect.)

The client starts using the database

At first there’s overwhelming happiness from half the employees, while the other half won’t even touch it cause the database must have the plague. Slowly but surely the head of the firm will get everyone using it. That’s when the chaos hits. Requests come in from left and right and of course, you still have some bugs to iron out. We generally do free bug fixes for 3 months after the release date. That is the industry standard. Of course, we tend to be more lenient than not, ssh…

Here come the modifications

We recommend putting those on a project named Phase II, so the client has a clear understanding that A) those are not bugs (something that was programmed faulty), B) what needs to get added to the database. Since we charge for estimating (because it is a lot of man hours to provide with a somewhat accurate account of how long the work will take, therefore how much it will cost), people elect to just pay up front, get a discount and have us work the time off. This seems to only work for awhile. At some point or another every clients starts questioning the funds put towards continuous development. I have a client whose database was developed by them and we just came in to make modifications, to make the database more modern, better-functioning, convert it to FM12 and add bells and whistles. After working together for about a year I get the question: we’ve spent over x amount of dollars and we still don’t have a working database. The client is regularly unhappy and not the kind of client I was talking about in the beginning of the article. Why is that? Let’s see. From the client’s standpoint, the requests are simple, I just want a new shipment section added to my database. Sounds simple, right? Yeah, it’s as simple for the trained developer who receives clear instruction as it is for the NASA to launch another rocket. Every adult brushes their teeth every morning (one would hope) and none of us think about whether we pick up the toothbrush with our left hand or right, how much toothpaste to squeeze out and how long and with what motion we’re supposed to brush. Now, try to have someone stand next to you, who says, wait, you left out top-left-3, and you have a speck in between 4 and 5. Oh, and you need to massage your gums, too. And what about flossing? Look what you’re doing, you ran out of toothpaste, and you’re dripping on the floor, go get the mop! At some point you’d put the brush down and walk out of the room. And the 3-minute task certainly ended up being half an hour. Hope my example illustrates my point: without clear direction it’s impossible to perform any task. Now, let’s add to the mix that people actually pay for your time, therefore you are bound to them.

When you perform modifications on a database—whether you built it or anyone else—any little change you make affects previous development, can cause bugs that you’ll need to fix that can cause other bugs, etc. It can get really hairy, even if the client has a clear vision and realistic expectations.

Here are the caveats to implementing changes:

  • Changes take a lot longer to implement than original, similar features;
  • Often there is no visual gratification;
  • Bugs keep popping up that further delay the work;
  • Client is thoroughly unhappy waiting for the change;
  • You end up billing 20 hours, even though you worked 30, because the client thinks it was a quick change that should’ve taken 5.

The bottom line is: nobody’s happy throughout the process even though the end result gets to be what the client wants.

The solution?

I think my solution will be to treat every modification/change as new development. We will create a mockup, estimate the work and charge accordingly. Then we’ll handle the next batch of changes. It takes finesse to build a database on a solid foundation so you can add features easily later. We aim to do just that, so we’ll have the best chance to keep our clients satisfied. Another thing to pay attention to is mapping out phase II while working on phase I, so we can accommodate those changes  much easier when it is time to do so. You know, a stitch in time saves nine. Still you can have misunderstandings, but at the end of the day you’re still better off because both parties agree to what’s going to be done.

Comments are welcome both from developers or clients.

 

 

FileMaker Go and Barcode Scanning – A Workaround

We all know that there are differences when dealing with FileMaker Go vs. FileMaker on a desktop. I think I can speak for all of us when I say we’re grateful that FileMaker Go exists, but we have to admit it has caveats. But we’re resourceful developers, right? We will sit and try ti tackle any given problem, because that’s what out clients/bosses pay us for. Most importantly, we cannot sleep until we figure the issues out because it just bothers us when we’re presented with a problem that we cannot find a solution for.

We sell barcode scanners. We make sure all of our scanners work with FileMaker, and all of our Bluetooth scanners work with FileMaker Go (and, of course, Android and other devices that sport Bluetooth connectivity). So far so good, right?

I’ve been getting complains that it’s impossible to scan into FileMaker Go. When things dont work like they’re supposed to out of the box.

The Problem

In FileMaker Pro you can script the scanning process to show a dialog that you scan into. This is great, because all the scanners you can program (which is usually the default anyway) to send a carriage return (enter) at the end of scanning. Which means that when the scanner is done scanning your code, the “Ok” button will be pressed automatically and your script can continue what it’s supposed to do, whether that is the bring up the dialog to scan another code or do some crazy magic and analyze data. You, however cannot achieve the same result in FileMaker Go, because you cannot get the cursor into the dialog. Now, we can ask questions like ‘why’ and spend hours and days cracking our heads open and even email FileMaker Inc. to see why this is not working. Or we can simply create a workaround.

The Solution

You can download a simple file that demonstrates how you can get around the problem with barcode scanning in FileMaker Go. I used a field to scan into instead of the dialogue and two triggers so you can create records and keep on scanning. There’s one field and one button on this layout. Obviously, you will have to scrip the rest of your process.

We can take the load off of you by doing the heavy lifting. Scripting can be cumbersome, when all you want to do is just scan an item and manage your inventory. Let us help.

We sell a wide selection of Bluetooth Laser Barcode Scanners that work with FileMaker Go out of the box . Pair, connect and scan right into a field. Want to use the iOS keyboard? No problem, push the small button and the keyboard will pop up.