What Is Your Future?

Mike Gualtieri Everyday, you are in the trenches building apps that the business needs to be successful.  Our number one job at Forrester is to help make you better, faster and stronger.  That means helping you understand best practices, tools, technologies, architectures, platforms and methodologies that are aligned with your success imperatives.  But, it also means hypothesizing about the future of application development and especially what the future means to you.

Two future scenarios seem plausible - the incremental and the radical.  The incremental future is more of an evolutionary future where change creeps upon us slowly to meet the changing environment.  The radical future happens when the giant comet hits the earth.  There are many shades of grey in between.  Let's start with two future scenarios:

Future 1: Dynamic Application Developer Better development tools, architectures, patterns and development processes will allow app devs to design and deliver dynamic business apps.  The application development professional role remains largely unchanged, but they become more effective.  Successful application development professionals are those who are able keep up with the pace of business change and the dynamic business applications they require.

Future 2: Dynamic Business Developer A new kind of collaboration between application developers, business analysts and businesspeople will shift much of the responsibility of development to businesspeople. Businesspeople will be able to construct applications by dragging and dropping widgets, writing business rules in natural language or using other intuitive tools. Applications are developed collaboratively by businesspeople and application developers.  The role and success imperatives of application development professionals change dramatically.  Successful application development professionals are those who are best at enabling businesspeople to participate more in developing dynamic applications.

Future 1 is the incremental future - more and better of what we already have.  While Future 2, presumes a fundamental change that has been wrongly predicted many times before.  Coghead, an internet startup, is betting on Future 2 by providing businesspeople with DIY applications that use widgets and Amazon's elastic compute cloud.

Is there anything different now that makes Future 2 more likely?  Which Future is more desirable? What can you do to influence and/or prepare for the future?

Some questions for you:

  1. Do you think Future 1 and Future 2 are plausible?  Do you have another potential future scenario?
  2. What are the drivers that will influence the future of app dev?  Is there a comet?  If so, what does it look like?
  3. What are the pre-requisites in terms of tools, technologies, architecture and methodologies needed to enable these future scenarios?

What are your thoughts?

Categories:

Comments

re: What Is Your Future?

A very well constructed piece, I enjoyed reading it immensely. Concerning future 1 and 2, at the current time I tend towards the future 1 incremental approach. Why? Well, it goes without saying that more radical change is usually less likely to happen, and obviously, the future 1 scenario is happening right now. However, I'd like to propose a third scenario; one that uses both parts of the the two futures outlined as well as the evolution of a new kind of employee.For gruff old developers, one readily identified issue with using business people to develop applications is that the software development process usually involves problematic absolutes that must be accounted for. Programming languages are necessarily littered with deterministic statements and conditions -and this highly structured approach does not always come so naturally in a dynamic business environment. Conversely, most seasoned business people have experienced the frustration involved with a development team that seems incapable of producing the goods in a timely manner -business objectives are minutely examined and parsed, producing seemingly unimportant issues that are pushed to be resolved -hindering real progress.At times it's hard to avoid a "them versus us" atmosphere when the cultures of business and application development clash. However, that separation may be there for a reason; traditional business roles may include the expertise for business rules and success, but do not necessarily encompass the skills and knowlege of more detailed application development. Likewise, traditional application development roles do not usually embrace the necessary skills, knowledge and appreciation of business operations and rules.Further, at first look, the ability to use widget-like objects to create applications is very appealing, but closer inspection does bring to the surface a number of serious concerns that may severely limit the scope of use: interoperability, compatibility and communication between created applications and sub-applications (potentially using different creation software), security, testing and due diligence of new applications from both technical and business aspects and rollback capabilities to name a few.So what may be a 3rd future? A new generation of business and application development educated people may be in the pipeline. Business schools may not just educate students on the principles and practices of business, but also the necessary skills -or at least appreciation of -applying application development. In many ways a similar model has already happened with the introduction of business software; no self respecting business graduate should be incapable of operating a spreadsheet, presentation application, word processor or simple database.However, even with this new kind of employee, current software must still undergo transformation to become more intuitive and responsive to human input, as well as becoming more "intelligent" to create the intended results. I believe this will more likely result from processing power increases and a traditional incremental development approach as frameworks, widgets and wizards continue to improve, providing more usable DIY solutions to a more educated business *and* application development person. In terms of usage, I believe a bifurcated approach is likely; smaller businesses and individuals will use the approach outlined in future 2 to leverage the flexibility, and larger more complex (with concerns of control and interoperability) businesses will continue with the approach outlined in future 1.

re: What Is Your Future?

Congratulations Mike on the launch of this blog. As the leader of a web application development company I am very interested in learning more about the environment in which we work and aid in improving it.Both future 1 and future 2 are beginning to emerge.Future 1: agile development processes allow for a great amount of flexibility, therefore allowing applications to change as business needs change. As more companies practice agile (and other similar methodologies) the software side will be able to keep up with the business side. The happiness of developers in every changing environments is another matter however. For a smaller company such as ours (7 developers, looking for more) we can easily implement agile practices and gain their advantages. The enterprise space is more complex and political, and converting to agile is difficult at best.Future 2: one purpose of software is to model business practices and the business environment, and to aid in the action. DIY applications can be built, however, they will have to be application specific (i.e finance, HR, etc.). We are well on our way with speciallized widgets and web services. Once a user is able to pick and choose the components of their app and each piece talks seamlessly to the other, that future will be realized.Business requirements and the need for better communication between two or more parties will (and do) drive web application development.There are many tools to development software. What needs to be enhanced is the ability to tie together disparate systems. Many applications publish their API however they are still "walled gardens" of information. Companies will need to open up and let everyone in. The challenge then is adding value in order to be profitable and open.Thank you for starting this blog with some insightful commentary and great questions.

re: What Is Your Future?

Hi, i'm eager to read more on this subject.Since i began my professional carreer (in 1994), i've been involved in the banking industry, the telecom industry, the legal industry and now i'm back on banking. Apart from the ever present "development people never catches up with business needs" that you mention, there is only one other issue that has been allways there and i believe is the real cause of the problem: data integrity and consistency.Most of the problems that developers handle everyday are related to discovering the "use case" that makes things (data) go wrong. It is even more important today, when all kind of services exist ONLY if the proper record is present in a database. How big is this issue? Well, many companies run watchdog programs that scan for known bugs and fix data records, because it is the most cost-effective way (or even the only way) to fix their hiper-complex systems.This complexity is growing faster every day and, while better development methods are VERY important, i don't see a solution to this in the near term (i regularly see good/seasoned developers fail to figure out and check semi-obvious failure scenarios). The hype going on today with the widget/gadget as applied to some simple personal need is the start of a (good) change, but somehow, i really can't picture any CEO happy with the idea that 3% of the clients lost service because of some weird misconfiguration of the data flow chain (yes, i think that "data flow" is a virtual "production line" on most bussineses). Software is about transforming (producing) data,not about the ifs, loops, objects or methods.Data integrity is difficult today even for programmers. A few years back, i've spent 8 months doing manual data reconstruction on a 5 GB database that was only 85/90% trust worthy, and each error group detected corrected a bunch of data entities related to software bugs that existed as long as 12 years before, that database was used to distribute money.In the long term, i think that both futures will coexist, in the same way that professional plumbing or carpentry coexist today with DIY approaches, and that is a good thing (programming will suffer the same process that content creation is going thru today, it will be democratized).The main difference with software (versus carpentry) is that you don't see where the rough border is until things are very wrong (and that is: corrupted data, or "production line" stoped).Better development tools are important (and are probably emerging). Better (perhaps automatic) data integrity is not here, and this is what will limit (or enable) both futures from merging.Cheers!

re: What Is Your Future?

Nigel,Thank you for being the first commentor on this new blog and especially for your insightful comments. I think your notion of a 3rd future enabled by "new generation of business and application development educated people" is a pre-requisite of business developers. The question then becomes what skill set do these people have to have? To come up with this answer we have to look at what tools and technologies will emerge to meet this generation. I think your point about widget interoperability is a good one and I plan a post on that.Mike

re: What Is Your Future?

Robert,Thanks for your analysis of Future 1 and Future 2. Your comments on agile adoption for small shops versus enterprise are interesting. I wonder if the future of application development in the enterprise requires an entirely new organization model and a new development process. If one of the benefits of agile is reducing development cycles, what happens when the business developer is the developer? If the relationship between developer and business developer changes, don't we need a new process?

re: What Is Your Future?

José,Data integrity! I can completely relate to this having produced, massaged and fixed data for years as a developer. For Future 2 to happen we need to solve this for Future 1 first. I love your analogy about the DIY carpenter.

re: What Is Your Future?

I've been thinking about this the whole day.There is an extra issue (hidden, i think) between both futures (thou scenarios is probably better :-). It all came around the comment on "business developer is the developer".It is likely that market pressures will make biz people to develop fast to achieve low times to market (the DIY stage). When products are new, some mishaps are probably ok.What will also be needed is a methodology (and/or development tool) that eases the change from DIY stage software to more first-grade implementation suited for mass-consumers. Glitches are usually ok with first-adopters.I do not use twitter, but i've seen all kinds of complains about it being down (there is even a web site www.istwitterdown.com that checks it). Users say: if twitter wants to get mainstream, these glitches must be solved.Complete rewrites are a problem in this "crossing" and that must also be worked out. We all know about rewrites and how costly (and late) they usually are...

re: What Is Your Future?

Also: may i suggest that the "posted by" line be shown before the comment?Cheers!

re: What Is Your Future?

Hi José,I agree that we will need to look hard at how existing methodologies can be adapted for participation by the business developer.Another potential problem are business developers creating ad-hoc applications like mashups that then turn into mission-critical apps. How many times has a business developer messed around with Microsoft Access to write a simple report and it morphs into an app that is all of a sudden running a multi-million dollar business?Looking into getting a posted by line before the comments.Thanks

re: What Is Your Future?

Mike, these are really great questions.And I am for half of scenario 2. Why? Because we see that collaboration between business people and developers actually working every day among our installed base of OutSystems customers. And we also see a new breed of professional business developers emerging.However what we don’t see is business people _continuing_ to create applications. And the reason for this is that they don’t need to. Business users build their own applications, first and foremost because of lack of response from IT. Before business goes rogue and starts creating their own apps they try to get IT to do it.So what we have been doing is bring developers close to business by simplifying collaboration and creating conditions for business feedback to be easily captured and acted upon. Business sees their changes reflected in the application in hours or days instead of months. The natural project methodology for this is Agile but Agile represents a fundamental different way of building solutions. You have to assume your business application is never stable and will be changed in the next iteration as business learns what they really want by experimentation and demos.This creates pressure on tools. I would say that two fundamental tenets of future tools and platforms are the capacity to accommodate extensive change fast and the enablement of collaboration among all stakeholders in the development and maintenance process. For example, our platform reflects an architecture where the whole spectrum of possible business change can be reflected robustly without having to retest the whole application. Most business feedback requires simultaneous changes in 1) the service APIs exported by existing system or records, 2) master data models, 3) user interface as well as 4) processes and business logic. We had to work backwards and enable validation and deployment technology that would enable cheap, continuous upgrades of changes across all these areas.And then... people. Our single, biggest challenge has been the transformation of the role of the developer. With tools addressing and hiding a lot of complex technological aspects of these solutions our typical developer has evolved to become business domain savvy, good at explaining tradeoffs to the business and concentrating on adoption and user experience. The challenge has been channeling the great technological minds we find everywhere into extremely successful and predictable application delivery experts that have to deliver every 2 weeks.There are two other trends that are impacting this landscape: SOA and SaaS. Amazingly both fit nicely into this vision. The architecture of SaaS platforms simplifies real-time collaboration between business and developers and features like remote centralized sandboxes enable the maintenance of vertical integrated versions of applications needed for agile projects with multiple developers. As for SOA it is too bloated and overloaded a term and it justifies a post on its own.Truly meaningful questions. Thanks,

re: What Is Your Future?

Mike: We communicated on that subject before so I appreciate that you highlighted this blog to me. It is a very important subject. I think your Future 1 and 2 are both unlikely. I propose that the change will be radical in principle and smooth in reality. F1 is too expensive and not enough flexible and user oriented to stay except for background mass production. F2 is the way promoted by Coghead and some BPM suites for front-end user processes. I call it IKEA-style process self-assembly. That will not be good enough either because it is too limited for large corporate IT. The good news is: business users will need corporate IT people and the good news is IT will not be doing programming. I propose that we need software that can be setup by IT in a short time to model all the entities a business needs to operate and then can LEARN FROM THE BUSINESS USERS how their processes operate. Don't ask business users to tell anyone how they work, because they can't. And if you encode processes in ANY WAY - with or without SOA/BPM or via SaaS or not - you are killing corporate agility. Software has to support the user not replace or dominate him and it has change as change happens and not after tremendoues analysis efforts. You might ask: So how would this software actually learn from the user? Good question, but we answered it.

re: What Is Your Future?

There is another factor that, IMHO, will push us more toward Future 2. The software development process itself is ripe for automation. With a good software engineering automation tool, I believe that more than half of current software engineering activities could be automated. Suppose you had an expert system for manipulating computer languages, with a rules language that allows any competent senior software engineer (with training) to specify the automation of code analysis, re-engineering, and even translation of a wide variety of computer languages, including assemblers, 3GLs, 4GLs, XML, and HTML, as well as proprietary, scripting, and data base languages? Such a system would constitute a _meta-tool_ -- a workbench for quickly automating software engineering activities. For each software engineering project, a repository of existing automation rules would be searched to see to what extent the required engineering tasks have already been solved, and new rules would be created for whatever hasn't. The new rules would then go in the repository for future reuse. These rules would comprise a serious competitive advantage to the organization that develops them.As the creator of precisely such a meta-tool, I believe that the widespread adoption of such an approach will accelerate the current trend toward "meta" -- a more abstract view of software engineering, systems architecture, and data. This in turn will accelerate the separation of the sheep from the goats, as fewer and more powerful software engineers do more and more of the work, rendering lesser lights obsolete.