|
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.
|
