Yesterday I had the opportunity to present to Computer Science students at Queen Marys University in London.
For the past few years we've taken under-graduates from Queen Marys on year long placements within the Application Development team. It's a great agreement for us - we get bright, young talent into our development teams in exchange for mentoring and guiding interns throughout their stay (plus they get paid!)
Yesterday we wanted to show off ServiceNow and attract new talent from this years crop of future developers.
I went along to their Mile End campus with our development manager, Ross, and Arya one of our current interns.
Here is the presentation I gave to the students.
Disclaimer: Some of the images I found on Google image search didn't have a definitive licence agreement attached. Please contact me to have these taken down if you feel they infringe your copyright and so on
I wanted to get across to our audience that writing Enterprise software is hard work. Writing prototypes is easy. Writing software that suffers with quality issues is easy. Writing bullet-proof software that works in the hands of your customers (all of your customers!) is really tough going.
Not at all like in the movies.. when Jesse Eisenberg has a great idea, opens his laptop and starts typing. Normally with a musical montage as you see him writing on a whiteboard... more typing... closes laptop and he's done.
I must have missed the scene where Mark Zuckerberg slammed his laptop shut after failing to get his automated tests running correctly and stormed off home for the night.
Photo credit
Photo credit
I wanted to back up my claim that enterprise software delivery is hard with some statistics. The numbers above come from the Standish report and illustrate that, as an industry, we don't do a great job on delivering projects.
- We deliver projects that are late, over budget or under the original scope
- We spend a lot of time writing requirements for features that aren't built
- The features we DO deliver (late, over budget etc) aren't always the right features and dont get used
- We should accept that we always know more about the solution after the first release
One of the reasons for this failing is the characteristics of the "Waterfall" methodology (Photo credit)
Waterfall promotes handling work in stages. Requirements written before Design. Design complete before Implementation and so on.
The problems with this approach are numerous. A delay in one stage guarantees delays in others. Developers are handed features that are already designed and have little connection to the business problems the requirements aimed to solve.
Developers write code and hand it off for Verification (Quality Assurance). Not a great solution for delivering on budget and on time.
Additionally Waterfall development defers value. No value can be delivered until the very end of the project when the entire solution is delivered. This makes the risk of delay and requirements change more acute.
I asked the Comp. Sci. students if change in a software project was good or bad. They were slightly conflicted.. wanting to say that it was good because it is a better solution for the user but aware of the difficulties in handling Change in Waterfall.
We talked about the Project Triangle and how all projects start with a balance between Cost, Scope, Time and Quality. And as Waterfall is prone to delays there is always a tension between the 4 dimension of projects. Inevitably one factor must be weighed above other - we want to deliver on time regardless of cost or scope - and how quality is normally going to suffer whatever happens.
So in ServiceNow we use the Scrum methodology to build software in an Agile way with the above benefits.
The first benefit being that we are able to deliver benefit to our customers (often internal customers) on an incremental basis. Rather than waiting for value at the end of the project we deliver after every iteration.
ServiceNow is built using ServiceNow for all of our process needs. As one student asked we do store our code base in a Source Control System outside of our own product. The fact that we use our own software to run our business requires engineering discipline and good practices, including code review, automated testing and so on.
I explained to the students that as a Software-as-a-Service company we recognise that the Service aspect is our primary focus and our top priority.
As a developer you tend to live your life in 2 week blocks of time working on sprints. We took the students through a typical 2 weeks of a developer.
Daily 15 minute standups....
Randomly building spaghetti towers
Retrospective sessions that encourage the team to review the sprint... what worked well, what didn't work well. How can we improve.
One of the most impressive things I've seen at ServiceNow is a culture of self-learning and self-improvement.
It was great to be able to present to bright under-graduates at Queen Marys and hopefully we'll be able to attract a few of them to spend a year at ServiceNow in a role I tried to explain above.
1 Comment
