|
|
|
Productivity @ Large Target App : 10 files, ave 20 fields per file, 3 keys & 3 foreign keys
Why should I spend a grand? (1K) Well, if marketing want me to cough up that kind of money the product has to pay for itself, and soon. Christmas is the sticky time of year so assuming I splash out now I have 6 months to make up the damage. I can probably pull in 2K per month, so to make up the K I lost I need to gain two billable weeks. IOW I need to be 10% more productive. Can TS deliver? Decent dictionary : 8.34 hours. Relations, validation & no corruptions. => 0.17 hrs 50 hours goes to 42. 16% improvement. Hourly rate goes up? What about new data? Field pools & picture pools & data modeller. Is that compelling? Rational & logical that 16% is compelling. Unbelievable. People do dcts then forget them. What you need is something you work with every day that makes a difference. Where the machine is taking away some of the grunt. 3rd normal form : Currently we populate the longs, and if there is a key on those longs we populate a sort order for that. We have added a couple of new bits of syntax to the user options in the dictionary. On subject ID field : DISPLAY(Sub:Title) On author ID field : DISPLAY(Aut:FirstName,Aut:LastName) Browses populate secondaries, update forms use a drop combo or lookup button and the report wizard populates the secondaries. Once only work on dictionary, better yet once only work you may not have to do …
50% improvement on original productivity. Double your RAD, but get it right. The wizards now produce code that is very functional, totally reliable and utterly predictable. In fact, dead boring. The problem with wizarded code is it all looks the same. You can have any screen colours you want as long as it is black on grey. Any screen layout you like as long as it the default. You like 13 dlu buttons rather than 14? Tough. From what I’ve show you so far the apps are just as boring as ever, it is just the RAD that is startling. And even that isn’t that spectacular. Sure we are industry leaders anyway, and a 50% improvement is well worth the entrance fee, but it is generally acknowledged that if you want a revolution that can shake the industry then you need a whole order of magnitude. If you are 10x quicker then it radically alters what you can do, 2x just makes life easier. So what I really want is a new kind of borg that does everything I’ve seen so far, but that also allows me to completely re-design the way my app works, brings my visual interface cruising into the late 90’s and at the same time reduces the amount of work I have to do by a factor of ten. And, believe it or not, that is exactly what we have. <Show borg> Notice a standard wizard type interface. Defaults button :
A factor of 5. Close but no cigar Let us put a factor of 5 into context. In our 50 hr scenario, the spec is in the e-mail Monday morning. Work all week, skip lunch hours, stay and hour late each evening and the program is just ready for testing by the weekend. The following Monday irons out all the problem. Now the memo comes Monday morning. By elevenses you have the app working to demo-level which enables you to flush out spec flaws leaves the afternoons for all the exceptions. Tuesday through Friday down to the Golf club…. Let us look at what our development now consists of : Exceptions. Essentially our Borg is an autopilot, that will cruise through your development schedule doing everything your way. The only time you have to step in is when there is an exception to the information available in the dct or in app styles. And your day is spent hacking those. Now, as the astute amongst you will have spotted I have one button left. This is your detail tree. You could consider it to be the ‘work list’ your Borg is going to implement. And you can hack & change to your hearts content. You do need some work, by definition, but you specify at a higher level (I don’t want this field on this report) and the Borg does the rest. You can also change any of the defaults you require to be locally applied.
So there we have it, an automated assistant that produces apps the way you want, in one tenth the time it takes you today. And gets it right first time, everytime. We have a product that is evolutionary in its’ usage but revolutionary it effect. So what do we do now? Start getting flash. You see a lot of the exceptions you would change in the detail tree are really dictionary specific rather than application. What do I mean by that? Well take our book file, with 3 keys, primary, authorid & subjectId. You will never want a book browse sorted by authorId, only by author. There are some fields you will never want on a report (such as subject Id) but you might want on an update form to hasten user entry. IOW quite a few exceptions are not really exceptions at all, they are simply high level data concepts that didn’t get into the dictionary. So, we’ve put them in the dictionary. Again the user options field is used to allow you to specify additional sort orders, which fields should (and shouldn’t) be populated in different procedures. To specify logical groups for fields so that the update tabs are populated logically. Now these won’t always be enough, you always need the override, but let us assume our dct is well specified and let us see what effect it has :
50x faster, and for the second application ….?
|