 Right, so our next presenter is John Cruz, who's going to be talking about avoiding development monoculture. Please make him welcome. So we have my slides, my titles, my little guys make sure I don't do anything stupid. They're sent by my family to make sure I stay online. But what you care about today is the idea and discussion of avoiding development monoculture. Probably what do I mean by that? Basically in the concepts of biodiversity, monoculture, bad. One thing over and over, only one, makes you vulnerable to problems. In software and development, we have developer monoculture where you have certain approaches that you might think are a good idea, but really cause problems, some that maybe you just haven't considered, and that's usually the case we run into. But overall, what keeps happening is pain. You want to avoid the pain. Oh, and just to clarify, I am not attacking C-sharp implementations or anything like that. This is a completely different mono. So who here are familiar with Abraham Maslow and his saints? A few in there. What's well known is his hierarchy of needs where you prioritize what is going to drive an individual depending on what he achieves and can go on to next. Only second to that usually is Maslow's maxim, which says, can be paraphrased as, when all you have is a hammer, everything looks like a nail. So how many people have ever tried to use a web framework to do a handheld device app or something like that of you, you know, not completely unheard of, things like that, where you just, you got to get something done, so you go to do it, you don't know what you're doing, you know you don't know what you're doing, but you don't have time to figure it out. Well, those are the times that start to hit you most painfully. So now that we know, you know, that you want to avoid pain, you want to avoid the problem, what do you actually do to make that happen? So I like to summarize this as, what you need to do is think different. In this case, you need to consider several things. First of all, different users. There is no one single user. Most things come there to bite you, especially when you've been in development for a while, anything commercial, definitely, or in-house, or IT department, any of that. Different operating systems. And in this, I don't just mean Linux versus Windows. We're talking Ubuntu versus Debian versus, you know, Fedora or some of the odd ones. Different display. It's not hardware monitor device is what I'm speaking of here, but different types of display, your output and your interaction. Different hardware. Now that's where we come into some very interesting aspects that used to be an obscure problem for some people elsewhere in this little division way off in the corner, you know, about ten years ago. Now, here's a question. How many of you have a smartphone? Yeah, probably three quarters at least. How many of you had programmed or installed some piece of software onto that phone? This is many well over half. So you have that now in your life. Imagine how many of your in-customers or consumers or users will have those issues. Different modularity starts to get a little more abstract into development and approaches and architecture. Different languages, and in this I mean computer languages, not, you know, natural spoken languages, and different tools. That's where we have some interesting fun. So first, to run over the idea of different users. You get different people who are very, very different. Some people say for usability testing, you can get three to five people to test your software and you're covered. Problem is you have to get three to five different types of people. If you go down to the secretary typing pool and pull three people up and have them test your software, they're not going to find everything that the kid who's been playing Xbox since he was five will find and do. It just happens. Also one size fits all doesn't exist. There are some good TED talks on this, especially about spaghetti sauce. So if you Google up TED talks spaghetti sauce, you'll discover a really good presentation about exactly why this is just not, as a concept, not viable. The reason you can't quite make that one UI to serve all your users is because you can't unless you only have a user base of one. But then again, maybe tomorrow you're going to try to do something different and you're going to make yourself upset. And so some of those issues are the job and industry. A graphic designer is going to behave different than a programmer. An IT admin is going to behave different than your secretary or receptionist. You have to factor those things in, who might be using it and who might use it tomorrow. The age, I mentioned one thing, kids who have grown up on electronics from the beginning have certain habits that are very different. People who use smartphones or Game Boys or anything like that, their manual dexterity is different. They put a lot more focus on their thumbs rather than pointer fingers. People who went through college before, everybody carried a laptop with them, will have a different set of problems. Some of our best QA and one of the best producers I worked under, software producer was someone who did not grow up or go through college with computers, you send them down at your program that everybody else has tested and he'll break it. You don't know why, you don't know how, it's just magic. And then that leads into computer experience. That's probably more important than any of those other factors because you can have a very experienced older person, very inexperienced teenager. It really depends and that's going to drive a lot of what you're doing. Then to cover quickly, we have different operating systems. Now in this, what you're going to hit if you try to bring software from one platform to another, Java and write once, debug everywhere is a classic problem. Some programs just won't run. If you try to write on once, bring it somewhere else. Then another on the flip side, often one OS will do something that will solve your problem in a way that you never thought of solving and that you can bring back to the other platforms that you never know. So currently, I'd say what you're looking at, most important, Microsoft Windows, Mac OS 10, BSD, Unix and other Linux distros. You get so much different behavior, so if you don't ever test or develop or punch or throw it out there on these other systems, you're not going to realize what you're doing wrong. And one of the biggest things I've found is if you fix things on one operating system, you often fix it for another. The next thing I've done is say I'm going into some place and I'm going to do a Linux port of a Windows product with a shared code base. As I go through there, aside not having the business constraint to be able to just throw the whole thing out and start over with something good, I end up having to fix things. And as I go, usually what would happen is I'll find something, the compiler will complain because I'm using a good compiler because I'm on Linux. It'll show me, well, wait a minute, you're de-referencing this that's not defined by the spec. Does that even work? Well, the other compiler didn't complain about it. You go back in, well, you use your logic then. You look at the structure. You say, well, if this were to go wrong, what behavior might I see? Then you walk down the hall to QA. As you're there, you ask them, have you by chance ever seen that, oh, yeah, that's our top one, every producible costs us thousands of dollars a month and support calls bug. You find those things when you clean it up someplace that didn't show you the problems it began with. Because I assume you're all competent developers who are developers who would not knowingly throw out a severe bug. You don't want to ship something bad. But you just didn't know because your tools, your compiler, your operating system may be covered up for you. And even on that, different versions of Windows will count as different operating systems. Come next Tuesday, Microsoft rolls out a new patch. Suddenly one of their APIs is completely replaced by a brand new implementation behind the scenes and breaks everything you've done. So not even saying, well, I'm only on Windows. We'll save you. And now here's one aspect where I start to think of a clue of what you can do, even if you don't implement any of this, think about this. Think carefully. If I'm going to write this program and have a display, this is somehow a GUI, perhaps, good chance of that, what am I going to use? The top two toolkits right now, GTK and QT. Well, if I write my app only for one, I'm going to be tied into that. What are the business constraints? What are the user constraints? What's that going to cause? What support headaches is that going to give me? What options for going to different platforms will that give me? If you think about this, you can come up with answers for everything and you don't get trapped. If you don't think about it, you find out your problem the week before you ship or release or whichever you're going to do. Web funded. What are you going to do there? Think about how would I decouple this so I take my bit-blit routines out of my core functional library, throw it up here in this other area of my program so I could switch it. Java programmers, if you want to do this, one of the options is to go to Flash. Adobe has their Flex solution that will take your back-end server-side Java and turn it into Flash display on the front-end. You don't have to code, you don't have to care about Flash. But if you've created a desktop Java app where your UI layer is separated from your core functionality, then it's very easy to swap in a different UI layer like Flex and then suddenly your desktop app is also a web-based app with all the lightweight, quick performance you need there and all the robust full desktop power when you run the desktop version. Things like that you can think of. Command line. This room is probably full of more people. Who here has ever run the command line piped into another command and to do something? Just most everyone. Think of that. That is your user interface. That is your GUI. Standard out, standard in, how to make it work. Then, of course, there's always one step further where you use VT100 or some library to give you actual on-screen text display. Or maybe if it's Java, you could use one of the plugins that turns swing into VT100 commands. Doesn't matter to you. If you've thought about it, cleaned your pieces away and brought it in. Then, of course, if you want to support that, you have to know that it might take you a little time to debug it. And you tell your manager, well, if we want to do this, here's what we will have to do in two weeks and then in five weeks and then in 12 weeks. Then the manager can come back and say, you know what? Guy's making the money decision said, no, don't do that. And you'll be off the hook. But by doing this, you separate your presentation from your information, which is a constant thing that's been going on for ages, including web pages, HTML from CSS, split them apart, make things work nicely, and you won't get surprised. Another difference we have to look at now is different hardware. Very, very common. I've got my phone. This is more powerful than desktop computers I've owned. It's got a keyboard. Your phone may not have a keyboard. Don't count on the keyboard being there. It's different. But more so than that, than the phones and the epics going back to low, slow wall warts. Dedicated Linux boxes. Things you can just plug in somewhere and they do a job. They're not fast. They're not good for gaming. But they can do a lot of things. Blade servers. Slightly the same approach is they focus a little more on power efficiency processing, not your usual dedicated desktop system. And that leads us into server forms. Go ask Google if you can use standard libraries even if you want to crank things up and go big. Sometimes you just can't. Sometimes you have to know that all you have to do is know to check. And you check your libraries and see what happens. Then, and again, in the small form factors aside from phones, we also have netbooks. How many people in this room have a network? Maybe a third to a half. So what are you going to do? If your software is written well and efficiently, it can scale down to that hardware, to that display. Well, maybe this phone probably has a lot higher display than a lot of netbooks out there. But I can't put as much on this screen because I can't see it. So even that, you have to consider the display density, the DPI, all that. And now this is where we get into some as a software coder, architect, developer, or tester, or user even. You might care a little about modularity. Who here is familiar with software modularity? Maybe a quarter. OK. So that's where you, instead of having a big program with one big routine to run, you break everything up. You create it. And by breaking it up, suddenly you can reuse those pieces. You can test them easier. You can run them through and do a lot more. So suddenly you've got a collection of independent LEGO building blocks that you can use to make your stuff happen that just won't work elsewhere. Different languages. This, I'm sure you'll get a lot of exposure to around here. If you want to learn a new language, you can. There are so many that take different approaches. And I'd just like to highlight that learning one helps you in a different one. Whereas when Java came on the scene with its interfaces, because multiple inheritance was a horribly tricky problem that most of the gurus, I know, tried to avoid because it would be a maintenance nightmare for the low-level guys, well, Java came up with interfaces. So someone realized C++, you just have an abstract base class with no implementation. You get the same functionality. Cross-pollinization between the languages you learn. And then sometimes either switching, throwing one language out and jumping with another takes a little learning time, but it might get your product out the door when otherwise you'd miss. Or mixing different components. One of those I'd like to highlight just is SQL. If you code to one SQL implementation, MySQL, try to run it on Oracle, how often will that work? Not too much. And then trying to squeeze in a little more, so we have the time, tools, IDEs. If you get one development tool, you're stuck. That may not be a problem if that's your choice. But look at it and find out. Number one, you can get a certain mindset that you just miss what else you're doing. You can limit the number of people who can contribute to your project, especially if you use a high-end commercial IDE. No one open source is really going to step up to help you. Or you can be stuck to when that vendor decides to change something, your toast. Oh, and by the way, double-double is no longer 80-bit floating point. It's now 64-bit floating point. Hope you didn't do any APIs with that. And then, for instance, they just get concepts wrong. Microsoft's Dev Studio did test-driven development, almost the exact opposite of what test-driven development really is. But at the last minute, the marketing team told them to turn it on and call it that, because it was the current rage. Another example real quick is Eclipse. It came from Smalltalk and other development systems. And it's got this weird thing of the workspace, which if you only ever use Eclipse, that's fine. But if you try to collaborate with other people, operate with other source control tools, it gets really ugly. So to summarize that, look in that. Because some IDEs will do a little bit of everything, but none of them very well. Dev Studio lets you make icons. Not too bad. It also lets you do graphics. I won't touch that with a 10-foot pole. Debugging might jump between a few things. Source control. Personally, I always go with a standalone source control client. Integrations often work, but sometimes they have bugs. And if you're a power user, you hit the wall quickly. And that's where you bottom line with certain tools. They try to be too helpful. If you want to do something, they're not going to let you. Because why would anyone want to do that? That's too hard. Let's not let them trip themselves up. So trying to wind up and not run over. Do we have time for questions? If we have time for questions, would anybody like to ask John a question? Let's put your hand up, and we'll run a mic to you. What would you suggest doing when you're pressured to settle on a standard set of tools? Sorry. Very good question. Especially in, now, would you say you're being pressured to settle in on a standard set of tools in a commercial day job, pay you bills kind of situation? Yes? Yeah. OK. Tell them no. So as much as possible. But if you've worked with management long enough, you can get them to listen and get some reasons. Is you don't want them to have tools as much. Well, if you can avoid a tool, that's good. If you can get them to allow a couple of tools, like for Java, Eclipse, or IntelliJ, this one does something. Can we allow either? Then it will also help your product be more robust, fewer bugs get in, easier to hire new people. We won't have to teach them tool A if tool B is allowed. And for some people, their minds just work differently. I'm best in Emacs. But for some things, I switch to Eclipse just to make it happen. Cool. Any more questions? OK. Everybody please thank John for a very insightful talk.