App Development Team Secrets

App Development Team Secrets
(How big corporations develop award-winning apps – fast)

Since a mobile app is designed for a single user, on a small screen, with an onscreen keyboard; you’d think they’d be easy to write. Yet many corporations, and teams, stumble and falter developing them.

Teams often fail to deliver award-winning apps because the screen is smaller, users don’t all behave the same way and … larger organizations have more (not less) stakeholders involved in the project.

For over 20 years I have helped businesses un-stick, stuck software projects. Over those decades, I noticed five problems that are common to all software projects – which are exaggerated when developing mobile apps.

And what you care about, is how to fix them so your team can develop top-notch apps – quickly.

To understand these problems, let’s put all the players into a little story. In the West we’ll have the wizards. The techno folks like me: software engineers, software developers, ‘puter geeks, ‘puter nerds.

In the East we have the end-users. The nice folks that will be using the software.

In the North, we have the Nobles – often know as the customer or the owner of the project. They decide that the project has organizational value. They allocate funding and are the ultimate managers of the project. In a sense, they are the key stakeholders. Often, a Noble will be a manager and they may assign a project manager to oversee development.

Finally, we have the Stakeholders from the South. For most software projects, this group consists of technical stakeholders that have key information. For example, in 2009 I worked for Ford in their Advanced Engineering Center. But I was no advanced engineer. I wrote software for engineers. I needed the engineers to give me the equations that they relied on for their calculations. The engineers were key stakeholders. What I would call technical owners of the project. That is, they owned key technical information, and had a stake in how the software operated.

With mobile apps we add more stakeholders. For example, because someone (not you of course) might be using an app while driving, lawyers may get involved in the app development. They may want language added to the app so warn the user not to use the app while driving. And marketing may want the app to have branding features. In fact, that is a common situation with app development.

If you think about it, you can bank with any browser. It doesn’t matter if you are using Firefox, Safari or Explorer – that is – any browser can be used to bank online – with any bank. So why does every bank have an online app? … Branding. That’s right – branding. It’s not security, or data encryption or privacy. It’s branding. So apps often have marketing as a stakeholder.

The more stakeholders, the more people who want input into the development process. And if we don’t watch out, all these completing interested can slow app development to a crawl. Or make the app unusable. Even worse, with all the other apps in the marketplace, we are completing with small, agile, responsive development teams.

We need our app to meet the needs of stakeholders and still satisfy end users. And if we want to be award-winning, we’d better do more than just satisfy, we better delight and excite!

Now that we have our players defined. Stakeholder are north and south, with managers being represented in the north and technical stakeholders in the south. Wizards to the west and end-users in the east. So let’s see how each group causes the five problems, and see how to solve them.

The Wizards from the west live by a slogan, “the software must always work.” And if you think about it, that’s a pretty good slogan. If you’re ever in a elevator, you don’t want the doors to open between floors requiring you to heft yourself up or shimmy down to your desired floor. And you don’t want the elevator to stop – trapping you inside. No one wants to reboot the elevator. Do you even know which three keys to hold to reboot an elevator?

These are the kind of things software types worry about. The software must always work is a good mantra to live by. Sure you can make fun of buggy software. But Wizards really want their software to really work every time you ride an elevator. And to work so flawlessly that you don’t even think about it. You just get into the elevator, press the button for your floor, and after a short ride of forgettable muzak, the doors open and you walk effortlessly onto your desired level.

That is a different thought process then the end-users from the east have. The end-users don’t have a mantra. They are part of a club. There are a lot of books that liken end-users to stupid people who don’t care and lie. That is, many business analysts books imply that end-users can’t be trusted to tell the truth about how they do their jobs. This is because, when end-users are surveyed about how they do their jobs, it is often different than what is observed by hidden cameras or observers watching end-users.

This discrepancy has all sorts of supporters who studied theory X and theory Y, etc. These studies and theories often miss the point. In my opinion, end-users are thinking about the task they want to do and not how they are doing it.

For example, at Ford and ProQuest, I was hired to write software. The first thing I did was to watch how the users were doing their jobs and how they interacted with the current software. There was a discrepancy in what they said they did on the job and what I observed they actually did. But they weren’t stupid. They had a perception of what they were doing, which differed from what could be observed. And difference was not as important as understanding the task the user was trying to accomplish. AND how they perceived what needed to get done. In other words, what a user tells you reflects the what and not the how. That is, an end-users is often telling you WHAT they are trying to do in a HOW language (as in how they accomplished a task). The observer is seeing the HOW, and thinking that is WHAT the person is doing.

If that isn’t clear as mud, let’s try this example. A woman says she is going to check her Facebook page. So she enters Google.com in the address bar of her browser and then searches for Facebook. Once she finds the site, she clicks the link and enters her information to login. A friend, puzzled says, you know you can just type in Facebook.com into your browser and go directly to Facebook. The woman says, “oh, well I’ve always done it this way.”

The woman isn’t stupid, she is just focused on the task and knows a way (HOW) to get there. If asked, she’d tell you that she GOES to Facebook.com. But really she GOES to Google.com first.

This marks a difference in how the Wizards and the end-users think. end-users focus on what works with software – not the how the software works. For end-users it’s like a light. Flip the switch and … LIGHT!

And this brings us to the first problem for development teams. What I like to call the Pink Button Problem.

Let’s say the end-users want a red button to indicate that this action is really important. So the Wizards are given the task to make a red button. Now remember the Wizards are really concerned with getting it right. So they consult tech books, almanacks and star-charts and verify what red is really true red. And they make a button the is the perfect red.

The end-users don’t accept it. They say, that’s not the right red. The right red – the wizards turn a few shades themselves as they become frustrated and shocked that they did all this work to verify the perfect red only to have all their hard work rejected.

Weeks go by as the two groups frustrate each other over a red button.

What is going on is best explained by the Husband Couch example. My wife and I buy a new couch (true story). We get it home and I know it will look best agains the north wall. After I move it in place, my wife sees it and says … “I’m not sure I like it there.” She suggests I move it to the south wall. And so I do. Again she says, “ I’m not sure I like it there.” And so we repeat the process with the couch moving it to the east and then west wall. Now that I am sweaty and panting she says, “maybe it was best against the north wall.” Frustrated, I move it once more – to the north wall – just like I said in the first place.

And this is the key to understanding end-users. They’ll know-it when-they-see-it.

Back to our red button. After a while, frustrated, the wizards bring out some paint swatches and ask … which red do you want the button to be? And the end-users pick out a nice pink. Turning a violent shade of red the wizard exclaims, “but that’s pink.” To which the end-user says, “that’s red to us.”

And that is the point. Often end-users know the right thing when they see it, but can’t describe it (and by it I mean the acceptable end result). This frustrates wizards.

Once we solve this problem, we’ll see that the other four problems are much simpler to solve. But we’re not done with this one quite yet. The wizard-end-user problem is the one that kills most software projects. The end-users don’t accept, buy-in or in some cases actually sabotage the software effort when the end result doesn’t feel right.

Software Development Life Cycle, and Agile often fail to solve this problem. I am going to show you how Model-Driven-Architecture does better job and is the secret to successful app development.

Each of these three methods has a drawback, but having used then all for over a decade, I think you’ll see why Model-Driven-Architecture (MDA) is perfect for mobile app development. Especially if your team is not in the same building (often called co-located).

The first method is the oldest. Software-Development-Life-Cycle often called SDLC or Waterfall was developed because developers (wizards in our little story) found that end-users had not disclosed every need, or the process had not captured every important detail of a software project. As such, the software when delivered, well … sucked. That is, the delivered software failed to deliver the expected result or return.

Well, thought the wizards, if we could only capture EVERY SINGLE requirement before the project began, we’ed get it right. And so SDLC or Waterfall was invented.

With Waterfall you capture all the end-user requirements in a master document. Define everything. This documentation process can cost millions of dollars and take so long to complete that the document no longer reflects the situation the intended app is meant to address. Then you had off the documentation to the developers (wizards) and poof – software written exactly to spec.

Well … it rarely goes quite like that.

The problem with SDLC is that you need two years to capture all the requirements and by then the environment has changed and add another year for the coding to be completed. And your looking at software that met a need three years ago.

You know how salmon die after going up stream. Well, making adjustment to SDLC is really hard to do as well. The system is meant to capture then code. And remember that red, I mean pink button? Remember, end-users know-it-when-they-see-it.

This is why Waterfall projects fail so often. The problem is that end-users are not great at describing what they need. And an army of business analysts are not always great at capturing what is needed. Then there is time needed to convert that captured data into documentation. And so it goes.

I loved working at Ford. Regrettably Ford suffered one of the most talked about software failures with a Waterfall project. They spent millions to document and develop software for their accounting operation. By the time the software was delivered, the end-users hated it so much, that Ford spent even more millions rolling it back (that is ‘puter speak for going back to the previous version of the software).

Not to fear – Agile, eXtreme and Scrum here!

After many years, programmers began to notice that if they released software in small bundles, end-users could redirect the effort early. Like driving a car, the driver sees the road and makes micro steering adjustments, Agile and Scrum projects release small parts of the software for review. This keeps the software on track and allows for fine tuning along the way. The result is *generally* better software. These newer methods are collectively known as agile. You may have heard of eXtreme programming, Scrum or Agile. They all share the same characteristics – short release cycles. The idea was that, if Waterfall was too long, why not shorten the cycle to get real user feedback for a part of the software instead of waiting until the end. And it worked … sort of.

In 2006 I worked at Menlo Innovations in Ann Arbor, an eXtreme programming shop. Agile does reduce bugs and it is a wonderful way to program. But it is expensive. While I was at Menlo, I never saw customer invoices. Yet, the lead project manager for the company said, and I quote, “our process is expensive.” Again, I have no way to argue against that as I never saw the client bills. But she blogged about that – not in a negative way. She way just saying, the results are great – but come at a price.

And Menlo is not the only company to bump up against the added cost of Agile. ThoughtWorks, another Agile shop, tackles the added cost by reducing compensation. Their programmers blog all over the net about their experience. While they generally like working at ThoughtWorks, a common criticism is that they are poorly paid. That is, ThoughtWorks requires teams to work at the client company site – which is all fine. But to reduce costs, teams are given low-cost accommodations, work long hours and for little pay. One thoughtWorks consultant put it this way, “I graduated from college only to get a job where I live in a dorm.” Personally, I am not sure that ThoughtWorks actually put him up in a dorm.

Don’t get me wrong, ThoughtWorks has published a great book about programing best practice (I love it by the way). And people who work for them like the experience.

Both companies are leaders in the Agile/Scrum programming industry. Yet both acknowledge the higher cost of Agile development. And each handles it in their own way. Menlo charges the client, while ThoughtWorks finds talent willing to work for less. I’m not finding fault – I’m just say’n.

So what makes Agile so expensive?

Most Agile teams use paired programming. And I loved working in that environment. But it does add to the cost. Paired programming is where two programmers sit at a station. One has the keyboard and types and they discuss their code as they write it. This done NOT double the cost because errors get caught quickly. Two pairs of eyes are watching out for trouble. In fact, it is must less expensive to catch an error when writing the code then in user-testing, debugging or peer-code-review (that is where an senior programmer goes over the code with a junior coder). Peer-code-review is often less effective than paired programming because in most pairs, you pair a junior coder with a senior developer. This mentor/mentee (protégé) relationship benefits both. And does so at lower cost.

However, the savings in error reduction does not outstrip the cost of double programmers. It still adds about 15% to the process. Then, most Agile teams duplicate key functions. To understand this, imagine that a company wants software written – we’ll call them the client.

In addition to a client project manager, the development team will have an internal project manager. It doesn’t matter that the client has an analyst, so will the development team. An Agile team is often bloated with staff: project manager, analyst (often called the voice-of-the-customer), testers – in addition to the paired programmers. Even if the organization has a project manager, analyst, and testers. The development team needs their own. And so … bloat.

While I like Agile, I acknowledge that short development runs (often called Sprints in Scrum lingo) are not efficient. Just like punching the accelerator in a car burns lots of gas, hair-on-fire programming has a price.

Now enter Model-Driven-Architecture. …

If Waterfall or SDLC puts end-user testing to the end of the process and Agile puts end-user testing kinda in the middle of development, then Model-Driven-Architecture puts end-users in front. And that is what Model-Driven means. The end-users make a model, then the software developers code it out. The model drives the architecture.

Let’s go back to our red-button problem. If we had just given the end-users some software so they could have colored a button mock-up, the button would have been colored with the lovely pink that the end-users wanted. Then the developers could have coded that into the final software – no frustrated programmers. In fact, you’ll find that programmers love Model-Driven-Architecture because they know exactly what to code. They have a model!

Happy end-user right from the start? Imagine software that is end-user approved even BEFORE it is written – crazy you say … here’s how …

When companies use Model-Driven-Architecture, they provide end-users with software that does more than just show screen mock-ups. The problem with screen mock-ups is that is doesn’t capture user interaction. And both the software screens and interaction are important to user-acceptance testing. Also, for data driven apps, there needs to be a way for users to interact with data. Data interaction can let end-users get a feel of how the app will really work. Remember, end-users know-it-when-they-see-it. As such, models need to have live data, be interaction enabled, in addition to having screens mock-ups. This is where wire-frames (which is a type of prototyping) often fail. To do MDA, you need modeling software.

Don’t worry, I’ll tell you how to get the software for free.

Until now, the lack of Model-Driven-Architecture software has prevented most companies from using it. Until now, companies that use Model-Driven-Architecture had to write their own software. Until now, that was the stumbling block – only large organizations could bear the cost of developing software to develop software.

However the companies that tried MDA, got great results. So how do you get the same results … I discovered secret free software.

It was 2006 and I left Menlo Innovations to start a new job with ProQuest. At ProQuest all the MBAs developed pricing models in Excel. They wanted me to write new pricing software for their products. This was pricing software that would price 5,000 products in complex combinations.

Having just left Menlo, an Agile shop, my head was filled with eXtreme programing methodologies. I soon realized that this was silly to rewrite the old software. The new Models already existed in Excel. All I had to do was code out from that model.

At this point my methods of MDA was not fully formed. So I created a hybrid system in Excel. Something between prototyping and MDA. It was so successful that directors at the highest level of ProQuest were looking at my work. I was a little puzzled because it seemed too easy. Take the models the MBAs had rendered into equations and turn that into code with a user interface. See, Excel has a programming language in it called VBA and slick user interface widgets like buttons and pull-down menus. All I had to do with build a user interface on top of the equations that the MBAs provided. The sales people (end-users) saw a pretty user interface and the MBAs had tested equations, so there was no recoding needed. Everyone accepted their part of the software. Once done, the whole thing could be recoded in Java … but that never happened because the Excel solution actually worked. The Excel app was in use when I left ProQuest.

So what did I learn that you can use?

First, Excel already existed in the corporation so there was no deployment issue. If you’ve ever worked for a large corporation you’ll understand how difficult it can be to deploy new software.

Next, I learned that everyone was already familiar with Excel. The MBAs could develop the basic equations that I would later code out in the final software. In fact, the MBA really tested their equations. I never had to attend a meeting about how they wanted to price stuff. I just had to understand their equations … or just copy them.

And while that sounds lazy, in fact, I let the technical stakeholders be the expert. They got to design the equations.

Lastly, I developed the first version of the software right in Excel. To some people’s surprise, Excel supports drop-down lists, radio buttons, check boxes, input forms and has a built-in programming language. If you look at the screen shot on my website, you’ll see the Excel app. It looks like real software – because it is real software.

I got glowing recommendations from that project and more work at ProQuest, but in the back of my mind a though was brewing. Could you do full MDA with Excel or Open Office?

Then one day, I attended a conference where a company was showing off prototyping software – just $20,000. I watched the seminar presenter and thought, “I can do all that in Excel.”

So what makes Excel such a good choice for prototyping and Model-Driven-Architecture? And how can you use it too?

Excel is a great choice because it meets the first three criteria for prototyping or modeling software:
* It’s already deployed in most organizations (or Open Office can be easily deployed).
* Most users are familiar with Excel.
* Excel has all the features found on a website, desktop app, or mobile app.

Excel (or Open Office) supports widgets (drop-down lists, radio buttons, checkboxes, user forms, dialog boxes, buttons). And the buttons are what is needed to make a sheet interactive. Excel has a programming language and tabs so that each page of an application can have its own layout. But more on how to use Excel for Model-Driven-Architecture later. For now, let’s just say that Excel turned out to be nirvana.

After I watched this guy demo a $20,000 piece of software I decided to see if Excel was really up to the job. So I designed a website – yes – in Excel. And it worked! Then I tried some database apps, not in Access, but in Excel. They worked too.

My next job was at United Health Care / I3 Global – now PharmaNet/i3. Due to a snafu, I was hired to work in the Ann Arbor, Michigan office; yet my team was in New Jersey. This was a good thing because it helped me further refine my MDA Excel solution. Because I was NOT co-located, the Excel model needed to be emailed back and forth between users. This was 2008 so dial-up was still used in airports. And many of the executives who used the software were emailed the latest version while waiting for a flight in London. Because of its small size, an Excel file can be emailed easily – another reason to stick with Excel for MDA.

My next project at United Health would test how well Excel could be used to prototype a server app. It involved three Oracle databases. The question was, could data from these databases, and another server, be combined and displayed graphically. If so, a final solution could be coded in Java. But first, a proof-of-concept application needed to be written. Excel to the rescue. Excel has the ability to gather data from servers, and with a little programming, allow end-users to manipulate that data.

My solution allowed the project to move forward. And, more importantly, this showed me two more reasons that Excel can create models for development.

* Excel files are small enough to be shared conveniently, quickly and efficiently.
* Excel can interact with a wide range of databases and servers.

Now I just needed to test my Excel Model-Driven-Architecture toolkit.

I was hired at Ford to write engineering software in to a Java app. Now I like Java just fine, in fact I have a degree in Java Programing with an Advanced Certificate in the language. However, Java is not a great language for prototyping nor is it a language that the average end-user can pick-up. As such, I used Excel at Ford for prototyping. And it was there there, over three long-term projects that I refined Excel sheets into my Excel Model-Driven-Architecture tool kit.

With that tool kit, I could let end-users design the screens, equations and interactions of a website, a desktop application or a cloud application.Then I would have a model, which had passed end-user acceptance-testing.

In other words, the end-users would have created working software that could be re-coded into the target language or platform – pre-tested, approved and debugged.

Thanks to a great bunch of engineers at Ford, the Model-Driven-Architecture / Excel toolkit works. In fact, it is what I use today to prototype Android and iOS (mobile apps). Excel as a modeling platform has these advantages:
* It’s already deployed in most organizations (or Open Office can be easily deployed).
* Most users are familiar with Excel. And users can learn how to add buttons and checkboxes to a sheet.
* Excel has all the features found on a website, desktop app, or mobile app.
Like buttons, checkboxes and the like.
* Excel files are small enough to be shared conveniently, quickly and efficiently.
* Excel can interact with a wide range of databases and servers.
* Multi page apps can be represented as Excel holds pages on separate tabs. And buttons can be programmed to jump to the right page (or tab). Thus emulating real program flow.

But most importantly, Excel can be used to write working applications. As an aside here is one of my favorite books on developing desktop apps with Excel (if you care to know more about that).

Having working software is a key concept of Agile. At every stage, which is called an iteration in Agile parlance, the development team delivers working software. The software may not do much at first, but whatever it does, it must work.

And that is what you get with an Excel prototype or model. A sheet that acts like the app you are trying to develop. Excel has lots of features built-in like: save and sort and pull-down list. Unlike most wire-frame development applications, Excel can make software that actually works now. This allows debugging and real end-user testing – with real data. And when end-users can really use a prototype, they notice the problems early. That allows quick changes and moves the project forward.

Because the users have something that works, they are happy. And the developers are happy because they have a model to target as they code. The developers are not trying to hit a moving target. The end-users have defined what they want. And if an organization outsources their final development, the model can be used to hold offshore developers to an unequivocal standard. This reduces the biggest problem with offshoring – cross cultural communication. A model can speak for you.

Having managed offshoring projects, I’ll tell you the model saved my bacon a number of times.

Model-Driven-Architecture, with Excel, solves the problem of over documentation that SDLC has, solves the cost problem that Agile or offshoring has, but it also solves five other problems common to app development.

First it solves the end-user vs wizard (developers) problem. The developers know what is wanted. They have a model. End-users make the model, end-users approve the model, developers code it out. East-West relations are harmonious.

But there are four other common problems with many software development projects. One is scope creep. Scope creep is where the project expands unproductively. This happens in two ways. Either the Nobles from the north invade the territory of the Wizards from the West or … the Wizards do it to themselves.

In my little world, the Nobles are the managers. Project managers, management, bosses – anyone with power over the developers. Often a manager will ask a developer if a feature can be added. Sure the developer says – wizards are nice people – they want to please. Unfortunately they need to hold the line on the desired deliverables. With a model, there is no debate. The end-users make the model and the developers, well, develop it. As such, if the end-users did not ask for a feature, the developers do not have the authority to add a feature. This kills one source of scope creep. Developers code to the model.

If a manager wants to add a feature, he needs to petition the end-users. And that process often stalls scope creep. End-users often only add features that they see as relevant.

The other source of scope creep is when developers do it to themselves. Often developers start writing code the make the app faster, use less memory or less storage. That sounds like a good idea. But who says the app is slow, or a memory hog or uses too much storage. That the is domain of the end-user – not the developer. With a model, developers only get paid to work on code the supports the model. When a developer works on code to make the app more efficient, but the end-user hasn’t requested efficiency, the developer doesn’t get paid. That normally stops developers working on stuff that the end-users haven’t requested.

The only time efficiency is justified, is when the app developed meets the model, but the end-users complain that the final app is too slow, users too much memory or uses too much storage. Then and only then, are the Wizards unleashed to work their magic of programming efficiency.

That leaves two problems for Model-Driven Excel apps to solve. Stakeholder buy-in and stakeholder acceptance.

On any project there are some stakeholders who have key technical information that must be in an app. They could be lawyers that need specific language in the app. They may be engineers or accountants that need certain calculations in the app. Or marketing may want icons to reflect a new branding initiative.

With Model-Driven-Architecture, each technical stakeholder can have their needs meet early in the development process. Thus insuring project support. Nothing is worse that developing for six months only to get a key stakeholder sabotaging the project at the eleventh hour. Model-Driven projects get early sign-off of majority stakeholders and thus has momentum and ongoing support. This is because these stakeholders are part of the model making process from the start. They put their marks or input into the model and sign-off on the model before it goes to the developers.

Quick sign-off is the last problem that Model-Driven Excel projects enjoy. Because prototyping in Excel is quick and inexpensive (in terms of people time), end-user acceptance allows stakeholders to have confidence that the return will be worth the investment.

Most software projects fail, not because the technology is wrong, but because the end-users never fully adopt the software. With a model, that the end-users can see, feel and experience, an organization can know if the investment is worth it. And know that early – before a huge investment is made.

So there you have it. How I develop mobile, web and cloud apps. With a ubiquitous application (Excel) and a methodology (Model-Driven-Architecture) that puts end-users at the start of development process.

If you don’t mind me tooting my own horn, I am the first person to but these two powerful peaces together. Excel (or Open Office) allows organizations to implement MDA. It is what I have been using to complete successful apps and you can use it to.

Please watch my videos (coming this week) that show you an example of using Excel for Model-Driven-Architecture.

For more information about:
My Excel MDA kit,
seminars, training,
app development consulting,
or app development,

Please contact – [email protected]