Behind the Scenes: Software Development in JMP® Live (2021-EU-PO-732)

[#1]

Level: Beginner

Aurora Tiffany-Davis, JMP Senior Software Developer, SAS

Get a peek behind the scenes to see how we develop JMP Live software. Developing software is a lot more than just sitting down at a keyboard and writing code. See what tools and processes we use before, during and after the "write code" part of our job.

Find out how we:

• Understand what is wanted.
• Define what success looks like.
• Write the code.
• Find problems (so that our customers don't have to).
• Maintain the software.

Auto-generated transcript...

Transcript

Hi I'm Aurora Tiffany-Davis, a software developer on the

JMP Live team and I'd like to talk to you today about

how we develop software in the JMP Live team.

First, I'd like you to imagine what software development looks

like to you. If you're not a developer yourself and the

picture you have in your mind is probably colored by TV and

movies that you've seen.

You might be picturing an oddball genius who works alone,

and the process for developing software is very simple. They

think really hard about a problem. They write some code

and then they make sure that it works. And it probably does,

because, after all, they are a

genius. If we were all geniuses like Hollywood says that we are,

this process might work for us, but actually we're only human,

and so we need a bit more than

that. First of all, we don't work alone. We work very

collaboratively and we have a process that helps us to

produce quality software. I'll point out here that there is no

one correct process for developing software. Your

process is going to differ across companies and often even

within companies. But what I'll do today is walk you through

what I would do if I were developing a new feature in

JMP Live.

First of all, before I ever sit down to write code, I have to

have some actual need to do so. There has to be some real person

out there who has found something in JMP Live that

doesn't quite work the way that they think it ought to, which is

a nice way of saying that they found a bug or they have a

request for a new feature. We keep track of these issues in an

internal system, and so the first thing I would do is go to

that system and find a high-priority issue that's a good

match for my skill set, and start thinking about it, and start

talking about it. The next thing I would do is try to understand

the need by talking to people. What kinds of users are going to

need this feature? How are they

going to use it? Then I would run JMP Live on my own machine,

and start to take a look at where the new feature might fit

into JMP Live as it already

exists today. Then I would bring up the code and start thinking

through how the new code is going to fit into our code base.

Once I think I have a good understanding of the need, I

would move on to the design step. And here again, my first

step is going to be to talk to people. I'll talk to user

experience experts that we have within JMP and I'll talk to my

coworkers and ask, "Have you worked on a feature similar to

this before? Have you worked in this part of the code before?"

Then I'll start to flesh out the design. I might write articles

and draw diagrams and share these around so that I can make

sure that the other members of the team are generally

comfortable with the direction

I'm moving in. Now I'll sit down and start to write some

code. And for this I'll use the integrated development

environment, which is a program that has a lot of

features designed to help us do better at our job.

Now that I've written some code, my first step is to find the

problems that I just created. I'm only human, so the chances

that I wrote 100% flawless code on my first try are pretty slim.

My first step is going to be to

use static analysis. Static analysis doesn't run the code,

it looks at it as though it's written down on a piece of

paper. An analogy might be spellcheck in Microsoft Word. Spellcheck

can't tell me whether or not I've written a compelling

novel, but it can tell me if I missed a comma somewhere.

Static analysis does that for code.

Now that I have found and fixed those very obvious problems, my

next step is going to be to look for less obvious problems,

and for that I'll use an automated test suite. We have

written a broad range of tests against our code. Automated

tests do run the code, or rather it runs a subset of the

code, provided a certain input, and expecting a certain output.

It's a really valuable exercise to sit down and write these

tests, because sometimes when I sit down to write a new test for

any feature, it forces me to really clarify my thinking about

how the software is supposed to work in the first place.

It also provides a really crucial safeguard against

colleagues accidentally breaking this feature in the future. So

it's a great way to find

problems early. Once I've written and run these automated

tests, I'll move on to some manual tests. I might run JMP

Live on my local machine, or on one of several servers we have

in the office and poke around and try stuff and just make sure

that it works the way that I

think it ought to. I may even look into the database that

sits behind JMP Live and keeps track of records on

users, posts, groups, comments, and make sure that records are

written in the way that I expect them to be.

Now I'm cautiously optimistic that I've written some good

code, and I've created a useful

feature. The next step is to ask my peers for their opinion. I'll

put this through peer review. Now in JMP Live, we put 100% of

the code that we write through peer review and the reason is

that we find it so valuable.

There might be something I have missed because I just sort of

have blinders on about something. Or it might be the

case that somebody else on my team simply has knowledge that I

lack. It's often the case in a review that the reviewer also

gets a lot of value out of the exercise because they might

learn about some new techniques.

Now that the team is pretty optimistic that we've created

some good code, I will finally commit my code or check it into

a source code repository.

We have a continuous build system that watches for us to

commit code, and when we do, it

analyzes it. It looks for really basic stuff like, are the files

named the right way and in the right place? It will also rerun

static analysis and it will rerun our entire automated test

suite. It does this in case someone has forgotten to do this

earlier in the process. Or more often, it could be the case that

something small and subtle has changed since the last time the

automated test suite was run.

So it does all these analyses and when it makes it through

this step, the code is now available for people outside of

the development team to take a

look at it. The first people who pick up on this are the testing

experts that we have within JMP Live and within the JMP team

more broadly. These are test professionals. It's what they do

for their whole career, and they're really good at it.

They might rerun automated test suite. They might add more tests

to our suites. They might run JMP Live manually and poke around

generally. They might run JMP Live locally and pretend to do

things as users that would be absolutely insane. What's the

craziest thing the user can do? And let's see how the software

responds to it. They're really creative with these test

scenarios. They might also run the software on various

different browsers and operating systems to make sure that our

software is flexible and robust.

Once they have signed off on this new feature, it's now

available to be picked up in our next software release.

Let me zoom out now and show you the process as a whole.

That's a lot of steps. Do we actually do all of this for all

of our software changes? Believe it or not, we do. However, this

process scales a great deal, depending on the complexity of

the work. If we have a really simple obvious bug, we'll step

through this process, but we'll do it pretty darn quickly.

On the other hand, if we have a very complex new feature, at

every step of the process, we're going to slow down.

We'll take our time and take a lot of care to make sure that

we get it right.

Now, anything that takes time costs money, so why is it that

JMP is willing to invest this money in software quality?

One reason is really simple. We have pride in our work and we

want to produce a good product.

The next reason is rather less idealistic. We know that

whatever problems exist in our

process, and in our product, if we don't find them, our

customers will and that's not great for business. So we

would like to minimize that.

Now no process can deliver

absolute perfection. And so we really invite you to stay a part

of the JMP community. Go to community.jump.com and let us

know if there's anything about JMP Live if it doesn't work the

way you think it ought to, or anything new that you would like

to see in the future.

That kind of real-world feedback is immensely valuable to us, and

we really welcome it.

That's all I have for you today, but I really hope that

you enjoy the rest of your Discovery experience. Thank

you.