P
PhilF
Guest
Having given this a bit more thought, I'd like to make some additional suggestions about how Progress might make better inroads into the young developer community. 1) Make it a project. Hire a few bright kids out of college, put them in a room for a month, and tell them to "learn our product." Then watch over their shoulders -- put someone in the room, use video, record their actual PC sessions, or perhaps all of the above. (I think of this is the "Jared Spool" approach.) You will find holes and plug them quickly that way. 2) Make it a wiki. Have a wiki page (or set of pages) dedicated to "getting started" docs, videos, tutorials, and the like. This should be well organized and will moderated; every link needs to be checked at least once a year. Make sure there is an easy way to leave feedback about things that don't work or are out of date. If the feedback is valid, publish it next to the offending materials until the issue is fixed; don't make everyone have to trip over the same problem. 3) Make it a class. Progress has some top people in many fields. Perhaps it could spare one or two of them for a year to teach a few classes at some local college or university -- say, one on Database Programming with OpenEdge ABL, one on Modern User Interface Design, and one on Working to a Reference Architecture. .Progress would make all of the necessary software available to the college at little or no cost -- much easier to do now that it has a subscription model with built-in expiration dates. At the end of the year, Progress would organize the course materials and offer them to colleges and universities everywhere. Partner with professors who want to teach something using Progress tools -- you supply the tools, they create the course materials for others to use. Maybe make a deal with students in these classes to supply them with a 2-year developer kit The more new programmers you can get using Progress, the more exposure Progress will have across the industry as they get hired. And the greater the likelihood that a few of them will advance to decision-making positions and pick Progress tools in years to come. 4) Make it a cookbook. This is a repeat of my suggestion from above, included here for completeness. Come up with an interesting project -- like AutoEdge -- but instead of creating it fully formed as if from the forehead of Zeus, build it a small step at a time. (I have looked at AutoEdge code. It is nearly impossible to learn anything from it unless you are already an expert.) In addition -- and this is critical! -- as you move to more advanced topics (PDSOE, AppServer, BPM, Kendo UIB, Kendo UI, etc.), make sure that the other parts of the project do not depend on these modules. For instance: -- If you need business rules, show how to do something simple in ABL, then show how to replace it with BPM. Users that don't have BPM can skip this, and the code will still work. -- Show them a working character interface. Then show them how to replace it with a a working GUI interface. Then show them different ways they can replace this -- with .Net, Kendo UIB, Kendo UI, KinVey, or what-have-you. But if they never do this, they still have a working application. -- Explain what options you might pick to create a new REST interface in PDSOE, and why. Then pick one and build and example. Maybe suggest additional work that might be done "as an exercise to the reader." If someone doesn't have PDSOE, but they need REST for some other part of the project, explain how to read and use the provided sample code -- which they can copy and modify for their own projects. -- Etc. This is a lot of work -- but from my perspective, it would be a tremendous investment. A good friend told to me at the conference (I won't name names), "there is no way to learn to use these tools without sitting down in a room with someone who knows how to use them." That's very nearly true -- and bodes poorly for the future. if I can sit down with a new language or tool and be productive quickly and easily, the odds are much higher that I will return to it. 5) Make it community driven. Have a place where people can say "I would love to see this," or "I had trouble with that," or even better "Here is something I wrote that you can use." 6) Make it a mindset. Take one or two people, and make it their job to think about the product as if they were new to it. I am sure that there are dozens more ideas like these. We are all (well, almost all) here because we like using Progress and want it to succeed. So let's think positive -- suggestions, rather than complaints. How would you bring Progress to the next generation?
Continue reading...
Continue reading...