I wanted to give a little history and a follow-up to my own situation. I originally crafted "The Case for Clojure" document for the developers in my company. The idea was to make a compelling argument for migrating our decent size codebase from PHP to Clojure. I would agree that showing your non-technical boss a bunch of code is not going to be the best approach.
The outcome for me personally, was that my employer decided not move forward with Clojure, and stick with PHP. In addition, I have left the company and am currently pursuing full-time employment as Clojure developer. Please hit me up if you are a Clojure company looking for a passionate Clojure developer. David On Mar 14, 2014, at 8:39 AM, Víctor R. Escobar <sefirots...@gmail.com> wrote: > Hi everyone, > > about David's document, I think you need to realize that it is a perfect blog > post for programmers. In a business usually the focus is in the benefit > (increase benefit or reduce costs). If I would be your boss perhaps I would > understand that you want to switch to another technology (for some reasons > that maybe not everyone understands) that will make the maintainability more > expensive and the extension more complicated. At least as it is exposed in > the document and as it can be understood by a businessman. > > Unless they trust your opinions more than their business reasons, try to > convince your bosses without show them a single line of code. It is just the > way some brains are cabled. Give them the economical reasons they want to > hear. I am inventing some of them: > > Faster prototyping to explore new business ideas. > Easily maintainable product and large easier to test (to avoid unexpected > surprises) > Faster reaction to error recovery (recovery on critic situations) > The code is scalable and parallelizable nearly without modify the setup > (remember how many startups died from success). > It is highly portable because it runs in the archi-well-known JVM (insert > now all benefits from marketing java). > A new hire can be ready to program in the time he learns how the company > works (say 30 days). > If you require to move to another technology you can port it with lower costs > than other languages (available directly in java, and easy to translate to > other lisps...) > And perhaps the most important: the best code for a company is the code that > doesn't have to be written. It is not what you have to do, it is how much it > brings to the company without waste company resources: show the technologies > that you can already use tomorrow for no cost at all because they are already > implemented and you only need to set them up (mention servers and hava open > source projects which make mostly all the work and just need to be adapted to > make everything). > > If you really want to convince them to get a yes, show them a working > prototype that looks to work (I repeat, a prototype). > > I hope this business approach helps. I had to learn it in the hard way. > > > > > El martes, 11 de marzo de 2014 22:09:43 UTC+1, Jarrod Swart escribió: > I'm about to be an early employee at a small startup. > > I will be the first technical hire and am a competent but not extraordinarily > experienced developer. The founders know this and hired me based on soft as > well as technical skills. > > I don't want to be the first technical employee and make a poor technology > choice that chains this startup from the beginning. > > My goal is to convince the CEO and other early stage executives of the > benefits of using Clojure in place of PHP. All the early founders have > worked in places that use PHP, and I have worked as a PHP developer with some > of them at other companies. For the past year I have used Clojure in my > personal projects and am comfortable with the language. > > I expect the following objections: > > * What is the talent pool like (for Clojure) and can we outsource less > important tasks to other developers. > * What advantages does this technology offer over something like PHP (from a > business perspective)? > * How will you cope with technical challenges? > > I have my own opinions but I would love to hear the feedback of others. If > you have good counter arguments to these or other objections you have heard > in the past I would like to hear those. If you have been in my position I > would love to hear about that experience as well. > > Also consider that these people are technical but not programmers. Any > benefits have to make sense from a business perspective as well. > > Thank you for your help! > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the Google > Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/8A3dnQIm100/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
