Just a link to an article that made me think about how the business may change over the next couple of years.
When I speak about business models, I present those that are known and already in the field. One of the questions I get asked is “How will the business models change in the future?”. Putting my finger on how the next generation of REALTORS will engage had been difficult. I recently came to the “collaboration” thought and have been using it on the road for a couple of months. This article gave a reason to believe I should continue these thoughts.
Although microtrends are characterized as having Personas, they can also be used in a good way. Personas should be used to model Culture 1.0 and Culture 2.0 users because they have nothing to do with the Real Estate model being used by the software user.
OK, this sounds clumsy so far. Here is an example of what I mean. Note that persona is used in two different contexts:
Persona #1 - Culture 1.0
Campaign marketing tool that sends out messages and tries to categorize responses into one of 4 pre-planned sub-campaigns. Typically these are built with “tree logic” (if response #5 is ‘yes’ then ….). Each sub-campaign is designed to meet the needs of a “persona”.
Persona #2 - Culture 2.0
Organic marketing tool that uses content to attract attention, then tries to determine the intention of the consumer. Intention is another word for collaboration in this context.
Some of the most important best practices in software engineering deal with automation; automated builds, automated testing, automated backups etc. It seems that developers are obsessed with automation, but why? Is it because they are lazy? I think there is something to that (and that’s a good thing, laziness being one of the Three Programmer Virtues), but I think that the main reason is safety. Automated processes have fewer errors.
Computers are really good at certain things, and one of them is doing the same task over and over again without variation. If your build process is ten steps long, and automated version will ALWAYS perform those ten steps. It will never forget a step and cause error down the line, and if one of the steps fails for any reason, it will stop and hopefully inform someone.
Because of this, I feel that every developer should be familiar with writing scripts. They can be shell scripts, Perl, Ruby or whatever. They just need to know how to create scripts for turning error prone, slow and tedious manuals processes into fast, easy and error free automated processes. In fact, I would feel nervous about hiring a developer that either didn’t know how, or feel the need to created automated scripts from time to time.
I also have found that this rule of automation is and should be applied to process outside of software engineering. Rules to filter your email are an example of this. The power of automation is what makes macros (properly used) in Microsoft Office and the Automator tool on OS X such important tools. With these tools the average user could, with a little time, automated those painful tasks, saving themselves time and preventing errors.
I will be from time to time providing examples of things I have automated in my own work and of how you can automated common painful tasks that every one seems to deal with. Keep an eye out for it!
