Thanks Sher. TL;DR The sys admin and management of versions and upgrades seems to take a lot of time from those who were once line-of-business application developers. Any ideas?
Longer version: Yes, it was much easier to work on the business logic when a developer's toolkit included a compiler, an editor, and a scripting or "job control" language of some sort, with terminals, printers, disk, and tape drives for I/O (pretending I never saw a card reader nor papertape). Now, I might be a grandma, but I'm not the sort who longs for the past. I'm working toward helping software developers write apps that meet the needs of people in the workplace today in ways that we will not need to do another rewrite soon. We would like to evolve the platform over time, while developers focus on the business logic. The app we are starting with was written in the '80's, and we are now doing the first rewrite rather than upgrade. We would like it to last a quarter of a century too before it needs another rewrite. News of Angular 2 is putting a wrench in things, but since it isn't here yet, I'll figure the Angular 2 team will be smart enough to give us the tools to automate the transition with the push of a button (wink), and I'm not going to try to put it out of my mind for a while. However, it is also the recognition that framework and library developers would be inclined toward encouraging their customers to do a rewrite rather than evolve the software that is so disturbing. "Wow, they would do that to us?" might be a seasoned developer's reaction. With open source approaches, did the industry just throw out backward compatibility as an important goal for new releases?!! Is there no trustee-for-the-industry who will help developers a bit better than this as we move forward over time? [Oh, yes, there's Microsoft, right? Silverlight.] I can see that with open source software, such as Angular and node.js, the choices and version skew issues could be painful. We selected full-stack JavaScript for this project, and one of the first comments I received was how we should move to TypeScript instead. Please, no!! We started with MongoDB, with a polyglot persistence mindset, and with what I have learned (not on the technical side) during the POC, it is now unlikely I will propose going that route. The industry moves so fast, it is difficult to identify even the high level choices for our run-time and development environments and keep those choices and versions the same for more than a week. Some of our current choices: Angular 1.4 ui-router formly jade restful JSON web services for CRUD "NoSQL" with a Not-only SQL DBMS, likely proprietary rather than open source node.js (thankfully io.js is joining back up) express (at this point, that could change) grunt (not gulp at this point, but I know many have switched) angular bootstrap, perhaps using ionic for mobile as we will need cordova in the mix for mobile, so we might switch to ionic altogether others libraries include: moment ui-grid morgan lodash font-awesome angular-aria, toaster, messages, animate developer tools include: git, webstorm, npm, bower Not to mention production deployment to the cloud, with virtual machine choices, OS, docker and the like Most of these are pretty typical choices, and there are various others not listed. Most will have new versions out regularly. Just to do "the rounds" and the sys admin tasks of keeping up with versions and new options, in addition to doing the quality assurance tasks to make sure that your app still works if you upgrade anything, could keep a small software company from having time to add functionality for the end-user into their app. >From Futureshock, Alvin Toffler, 1970 "New machines and techniques are not merely a product, but a source, of fresh creative ideas." "Each new machine or technique, in a sense changes all existing machines and techniques, by permitting us to put them together into new combinations. The number of possible combinations rises exponentially as the number of new machines or techniques rises arithmetically. Indeed each new combination may, itself, be regarded as a new super-machine." We don't want to switch from being application software developers to being sys admins for an ever-changing super-machine. We are looking for developers to switch from developing green screen (or screen-scraper GUI) apps to developing for mobile and web with current approaches. So I'm trying to figure out how to optimize the sys admin, version maintenance, and UX/UI functions so we do not have to hire dedicated staff in those areas, even if outsourcing some functions. I don't see a way to outsource the version-related sys admin tasks -- it seems that developers have to stretch more into sys admin. We don't want to ;-) If anyone has suggestions for how a small application software company might deal technically, procedurally or policy-wise with all of these versions and upgrades, some of which might require considerable work, I'm all ears. Would it be reasonable to ignore all new versions for a year or half year, for example? I doubt it. We will want functionality or bug fixes from the xyz version of ABC, which then requires the next version of another piece, and the project spirals into a Tim-the-toolman-Taylor effort ( http://www.funtrivia.com/en/subtopics/The-Handiwork-of-Tim-The-Tool-Man-Taylor-173310.html ). Should we cut down on the number of external dependencies in the list above? That's hard to do when someone has written what you want and would otherwise have to write -- it seems like a good idea to share code in this way. Thoughts? --dawn On Thu, Jun 18, 2015 at 12:02 AM, Sher Hurlburt <[email protected]> wrote: > Dawn, > > My first programming was also on a mini. I think our vision was clearer > in those days because there was less NOISE. We didn't care about font > style or size, no one discussed animation or transitions and our 'themes' > were amber or green. Less choice meant a simpler world and that naturally > lead to clarity. We could focus on solving The Business Problem. But > today...look at all these shiny things! No wonder our vision is corrupted. > > Setting aside the off-topic musings, I think it is insightful that > responses to your posting have been detailed and forthright and involved > persons clearly seasoned in this world. This is your Google community and > that resource is a consideration as you go forward with your project. > > Sher > > > On Tuesday, June 2, 2015 at 12:43:39 PM UTC-7, Dawn Wolthuis wrote: >> >> My musings below are all largely off-topic. >> >> Thanks Mo -- you are speaking my language. I've been sitting in mgmt >> roles since 1988. I'm stretching myself a bit with some hands-on coding >> right now, although I have kept my fingers in that too, off and on, over >> the past few decades. >> >> A lament for the software industry: Even when I have a team of developers >> now, I am hard-pressed to put as much functionality into production as >> reliably and as quickly as I did in the summer of 1977. I don't know if the >> software development industry can ever be that productive again from the >> standpoint of the organizations we are serving as when we were automating >> business workflows for the first time. Armed with a server (mini-computer, >> at the time) running on a token-ring network, a "green screen" terminal, a >> 3GL, and indexed-sequential files, along with runoff for doc, I could run >> circles around the developer I am today, although I know a LOT more now, so >> go figure. >> >> Anyway, yes, it is definitely important to consider risks and the overall >> business case. I'm coming into this project to address a business goal, >> rather than a specific technical goal, and I definitely learned a lot >> making a variety of both business and architectural choices and suggestions >> to date and doing a little POC with the MEAN stack. It is so much more >> complex to program today than it was in the 70's! I met Grace Hopper in the >> 80's and sometimes wonder what she would think if she saw how cryptic our >> software development is today. This is NOT the direction I was hoping our >> industry would go. >> >> cheers! --dawn >> >> On Tuesday, June 2, 2015 at 1:24:56 PM UTC-5, Mo Moadeli (CREDACIOUS) >> wrote: >>> >>> Dawn, I've been swamped at work so apologies for delayed response. If I >>> may, I want to perhaps add a different perspective that contains elements >>> that indirectly relate to your concerns but might also be of more direct >>> importance to the LOB decisions makers you originally alluded to. >>> >>> Speaking of 'decision makers', there is someone, a senior IT manager or >>> senior technical business manager, who (hopefully) should be thinking less >>> about the technical nuances of the options discussed), and more along >>> BUSINESS elements (even if the LOB is a cost center), and would be very >>> grateful if you can help them translate the technical SWOT (discussed >>> rigorously above) to a BUSINESS SWOT. If I were them, in addition to the >>> high-level technicalities mentioned, I would be considering the following >>> (very broad-brush) inter-related items: >>> >>> - risk mitigation: i.e.: Regardless of the final technical solution, >>> how can I reduce the impact on the business if something goes wrong (eg: >>> AngularJS x.x support ends unexpectedly or React.js never achieves >>> maturity/stability)? How does that compare with what I have today? >>> - constant or/added productivity: i.e. For each solution what is the >>> turn-around time and complexity to service the requirements of my >>> stakeholders and/or to carryout standard maintenance for a given lifespan >>> T? (eg: Angular x.x's inherently complex but robust vs React.js easier to >>> use but only-part-of-the-stack solution) >>> - (Human) resources: i.e. What is the level of expertise available and >>> support, how often, and for how long? (large AngularJS community and >>> support environment vs active and growing React community) >>> - And of course (opportunity) costs: i.e. What is the cost of >>> implementing my solution that covers items above and how does it compare to >>> the opportunity cost of not choosing the alternative? >>> >>> With the technical content you already have from your own research and >>> thoughts provided here, you need to sit with this person and jointly build >>> that case for each solution, openly and credibly. They will be very >>> grateful that you can couch the problem in these terms and/or help them >>> construct the business case in their own language. >>> >>> I hope this helps! >>> >>> Mo >>> >>> PS: In the main body I intentionally left out my thoughts on which way >>> to go because, frankly, I am biased! :)) However, for whatever it's worth, >>> and not knowing the specifics of your LOB, I believe staying on the >>> AngularJS track will more or less satisfy the business criteria above. >>> That said, in this day and age of rapid innovation (especially in software >>> infrastructure) a business (or LOB) can ill-afford a fire-and-forget >>> strategy, and must revisit their choices far more often than before and be >>> prepared to shake things up if stakeholders AND business requirements >>> demand it. The opportunity costs of inaction will out-weight the costs of >>> action more often than not. Regardless, the final decision is heavily >>> dependent--not only on technical merit--but business criteria as well. Good >>> luck! >>> >>> >>> On Tuesday, June 2, 2015 at 1:13:57 PM UTC-4, Dawn Wolthuis wrote: >>>> >>>> As much as I enjoy a good chat about languages, that was not the >>>> purpose of this thread, although I know I mentioned that JS fit a project >>>> better than TS right now. If someone wants to start a new thread regarding >>>> languages that meet Grace Hopper's criteria of sounding close to English >>>> (perhaps we have apps like Siri for that as the programming industry went a >>>> far different direction!), or languages that give you enough rope to hang >>>> yourself (basic, js, cobol, ...) compared to languages that hang you >>>> themselves or cause you to want to hang yourself, or whatever else there >>>> might be, I might even chime in. Right now I would be happier to accept any >>>> more comments in this thread that are more directly related to the original >>>> post. >>>> >>>> I now have advice from several sources and am leaning toward Sander's >>>> advice of choosing option b, upgrading to 1.4 before we dive into the >>>> rewrite, continuing to use ui-router. The second most popular response from >>>> folks I have chatted with is to bite the bullet and convert to the new >>>> router before we begin. The folks with that suggestion are far better than >>>> I am at coding and can just "toss things in and deal with it" better than >>>> I. With what I have seen so far, given I have been happy with ui-router, I >>>> am pleased not to have to start thinking like the new router, but that >>>> might be overly short-sighted of me. It seems to be yet another paradigm >>>> shift for no apparent reason (so I'm glad others are aware of the reasons >>>> and trust that they are good ones). I'm hopeful that ui-router will stick >>>> around for the conversion to Angular 2, so it might even help with that >>>> effort in the future. >>>> >>>> Is there anyone who can speak in favor of choosing option c and >>>> converting to the new router now rather than diving into a significant >>>> re-write without learning the new router first? >>>> >>>> --dawn >>>> >>>> On Monday, June 1, 2015 at 11:50:31 PM UTC-5, Anton Trapp wrote: >>>>> >>>>> Language wars. How funny. Hated JavaScript (came from Ruby and this is >>>>> still my favorite), with CoffeeScript I can look at it because it does not >>>>> look to ugly :) >>>>> Yes, some concepts (or the lack of them) show that not the most clever >>>>> people invented it yesterday and used all the experience from other >>>>> languages to do that. >>>>> >>>>> But to say a language is bad because people try to make it better over >>>>> the years as the intended purpose changes and it gets used by much more >>>>> people is silly. Every language that is used and after every new pattern >>>>> that proves worthy (DRY, ...) gets it's updates, otherwise it vanishes. >>>>> >>>>> And I am in the software business for almost 30 years. Saw many >>>>> languages and projects. Not a single one failed because of the used >>>>> language. Some failed because of people not able to understand how do deal >>>>> with the weaknesses of the languages and frameworks. >>>>> >>>>> And bashing around on something without any proof is just wasting my >>>>> time. JavaScript is definitively one of the most important and most used >>>>> languages today. Likely because it is unusable and all people who use it >>>>> are idiots. >>>>> >>>>> Really have better things to do. Out of this thread - have fun bashing >>>>> ;) >>>>> >>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "AngularJS" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/angular/glrlMKryAps/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > -- Dawn M. Wolthuis Take and give some delight today -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
