| The Ultimate Business Machine Technology, business And, not least, about by: Bernard Teo
|
Sat 07 Oct 2006 Make Work. And Real Work.Category : Commentary/MakeWorkRealWork.txt In Cocoa, if you want to know when the contents of a text field has changed, you assign the job of listening to changes being made to the field to the object that is managing your window (the window controller). This is called "making the Window Controller the Delegate of the Text Field". And this is how you do it - by linking the text field to the controller using Interface Builder:
This works OK in a beginner's class, but in a real application with many windows and many fields, it becomes a pain to link each field one at a time. What if you forget? It gets ugly with all these connections cropping up all over the place. It's complicated, cluttered and laboured - a sure sign that there ought to be a better way. I wanted to see if I can avoid doing all these linking in Interface Builder and still be able to tell when data has changed sufficiently that it needs to be saved. And from preferably just one place in the code. I spent days figuring out if that's possible. I tried everything. I sub-classed NSTextField, NSControl, NSText. I wrote my own categories. I traced the calls up and down the class hierarchy. I just refused to make those links in Interface Builder. In part, it's because I'm lazy. Part of it is because it's really too messy if you want to build things fast and yet want things to be precisely under control. And part of it is because I have faith in Cocoa's designers. It can't be that stupid. I went round in circles but I couldn't give up. Especially in an application like Luca, I needed a mechanism to tell precisely when it's the right time to enable the Save button, if I want to protect the user from saving inconsistent data and upsetting the balance of the accounts. And I need this mechanism to be simple, small, elegant, and easily implemented. I plan to build other business applications after Luca. If I can find a better way, I'll be able to build all these other applications faster. Then one day, I saw it. Just one line of code. And I'm off. Now, Cocoa is just like that - one line of code here, and another line of code there, and you get significant amount of work done. That's its beauty. But the reason I'm bringing this up is to highlight something else, using this experience as an example. And that is, how can you tell make-work from real-work, if you're overseeing software development? How do you tell when someone is working, when days go without measurable progress? And this is a double-edged sword. How can you tell that some programmer is not actually working, when he does in fact produce measurable lines of code? I can give you one example. Say, a programmer has to write a Unix batch job to process many thousands of records. It takes hours to process those records. So he writes his code, hits Run, and he stares at the screen and his mind is elsewhere for the next three hours, after which he finds bugs in his code, makes changes, hits Run, and in another two iterations, it's time for him to go home. If you're smart, you'll ask him why he can't just test his logic against a representative sample of records that gets run in a mere few seconds. And when he's done getting the logic right, do a test run against the whole thousands of records to see if the solution scales OK. That'll get the job done in a day, and let him know you know. And keep him on his toes forever more. But is it possible to understand and thereby manage the software development process (and make decisions on what platforms to standardise on, what directions to take, technologies to adopt, etc.), if you're not yourself a competent programmer? I'll leave this question hanging for today. It's the weekend after all. :-) |
Mac@Work
Services running on this server, a Mac Mini running Mac OS X 10.9.2 Mavericks:
all set up using MailServe, WebMon, DNS Enabler, DNS Agent, VPN Enabler, Liya and our SQL installers, all on Mavericks. |
||||||||||||||||||||||||||
