Without fanfare, a group of Big Thinkers in computer languages, processes and practices gathered in Zurich last month to try to create a definition for software engineering methods and theories. We wish them luck, but are skeptical that their effort will make any significant difference about how software is written, tools are marketed and students are taught.
The SEMAT group’s goal is an admirable one. Like theorists and practitioners in other fields, they see the need to bring our industry together. They see a need for academics and standards bodies to set universal definitions that can be taught in universities and practiced in development shops around the world. That’s a great goal.
They cite such fundamental failings as fads in software development. They worry that universities lag behind the industry in teaching what is being used in the field. They’re right on both counts.
The first SEMAT workshop resulted in the creation of six working groups to tackle, among other things, the creation of a language to define those universals. This effort might take years to yield fruits. And, we believe, even when it does, its impact on real-world software development will be minimal.
The last time Big Thinkers came together to take on software development, the result was the Agile Manifesto, a set of rules that real-world practitioners could apply to their development organizations to streamline work, reduce costs, and create better software faster and more cheaply. Although some theory went into the manifesto, the document resonated because of its sheer practicality. You could use the manifesto to transform a corporate develop team.
The SEMAT effort is rooted entirely in theory, with the goal of being able to define universals that encompass every possible software methodology. If a methodology falls outside the universals, more universals will be created to ensure that the methodology is included.
The work to bring teaching and practice together to advance software as an engineering discipline is indeed noble. But while these Big Thinkers labor to create those universals, there are programmers sitting in Boston, Brussels and Bangalore working long days to create and ship software. Development teams must do more work in less time to write applications for systems that have grown more complex. We’re not sure how SEMAT will help.
In our skeptical way, we wonder: If a methodology is defined but no one is around to care, does it make a sound?
Ads in the apps, 10 years later
For some developers, advertisements embedded into applications may represent a significant revenue streams that makes your company viable or a particular application possible.
Ads can also mean money lost. A negative ad impression is not better than no ad impression at all, and your customers can be left with bad tastes in their mouths about brands—and your apps—if they find ads too bothersome. But developed correctly and tastefully, embedded ads can prove to be a win-win-win scenario for consumers, developers and advertisers.
Technology is emerging that offers consumers a non-invasive ad experience. Video ads, sponsored quizzes and other interactive content can make advertising not only effective but also fun. In fact, some of those advertising technologies have also become so advanced that even a line is starting to blur between an app and an ad.
We applaud the advancements in ad-embedding technology and urge you to take advantage of it where appropriate. We also caution that you to make sure that it’s executed right. We know there will always be consumers willing to pay for ad-free versions of apps, while there will always be others willing to tolerate the ads in exchange for free software. It’s good business to cater to both groups of customers.