ASWEC Day 3 (SE Education Track), Keynote, “Teaching Gap: Where’s the Product Gene?” (#aswec2014 #AdelED @jmwind)Posted: April 9, 2014
Today’s speaker is Jean-Michel Lemieux, the VP of Engineering for Atlassian, to open the Education track for the ASWEC Conference. (I’m the track chair so I can’t promise an unbiassed report of the day’s activities.) Atlassian has a post-induction reprogramming idea where they take in graduates and then get people to value products over software – it’s not about what’s in the software, it’s about who is going to be using it. The next thing is to value experiences over functionality.
What is the product “gene” and can we teach it? Atlassian has struggled with this in the past despite having hired good graduates in the past, because they were a bit narrow and focused on individual features rather than the whole product. Jean-Michel spoke about the “Ship-it” event where you have to write a product in 24 hours and then a customer comes and pick what they would buy.
Jean-Michel is proposing the addition of a new degree – to add a product engineering course or degree. Whether it’s a 1 year or 4 year is pretty much up to the implementers – i.e. us. EE is about curvy waves, Computer Engineering is about square waves, CS is about programs, SE is about processes and systems, and PE is about product engineering. PE still requires programming and overlaps with SE. Atlassian’s Vietnam experience indicates that teaching the basics earlier will be very helpful: algorithms, data structures, systems admin, programming languages, compilers, storage and so on. Atlassian wants the basics in earlier here as well (regular readers will be aware of the new digital technologies curriculum but Jean-Michel may not be aware of this).
What is Product Engineering about? Customers, desirable software over a team as part of an ecosystem that functions for years. This gets away from the individual mark-oriented short-term focus that so many of our existing courses have (and of which I am not a great fan). From a systems thinking perspective, we can look at the customer journey. If people are using your product then they’re going through a lifecycle with your product.
Atlassian have a strong culture of exposure and presentation: engineers are regularly explaining problems, existing solutions and demonstrating understanding before they can throw new things on top. Demoing is a very important part of Atlassian culture: you have to be able to sell it with passion. Define the problem. Tell a story. Make it work. Sell with passion.
There’s a hypothesis drive development approach starting from hypothesis generation and experimental design, leading to cohort selection, experiment development, measurement and analysis and then the publishing of results. Ideally, a short experiment is going to give you a prediction of behaviour over a longer term timeframe with a larger number of people. The results themselves have to be clearly communicated and, from what was demonstrated, associated with the experiment itself.
Atlassian have a UI review process using peer review. This has two parts: “Learn to See” and “Learn to Seek”. For “Learning to See”, the important principles are consistency, alignment, contrast and simplicity. How much can you remove, reuse and set up properly so the UI does exactly what it needs to do and no more? For “Learning to Seek”, the key aspects are “bring it forward” (bring your data forward to make things easier: you can see the date when your calendar app is closed). (This is based on work in Microinteractions, a book that I have’t read.) The use of language in text and error messages is also very important and part of product thinking.
No-one works alone at Atlassian and team work is default. There’s a lot of team archeology and look at what a team has been doing for the past few years and learn from it. The Team Fingerprint shows you how a team works, by looking at their commit history, bug tracking. If they reject commits, when do they do it and why? Where’s the supporting documentation and discussion? Which files are being committed or changed together? If two files are always worked on together, can we simplify this?
In terms of the ecosystem, Atlassian also have an API focus (as Google did yesterday) and they design for extensibility. They also believe in making tools available with a focus on determining whether the product will be open source or licensed and how the IP is going to be handled. Extensibility can be very hard because it’s a commitment over time and your changes today have to support tomorrow’s changes. It’s important to remember that extending something requires you to build a community who will use the extensions – again, communication is very important. An Atlassian platform team is done when their product has been adopted by another team, preferably without any meetings. If you’re open source then you live and die by the number of people who are actually using your product. Atlassian have a no-meeting clause: you can’t have a meeting to explain to someone why they should adopt your product.
When things last for years you have to prepare for it. You need to learn from your running code, rather than just trusting your test data. You need to validate assumptions in production and think like an “ops” person. This includes things like building in consistency checks across the board.
Where’s the innovation in this? The Atlassian approach is a little more prescriptive in some ways but it’s not mandating tools so there’s still room for the innovative approaches that Alan mentioned yesterday.
Question time was interesting, with as many (if not more) comments than questions, but there was a question as to whether the idea for such a course should be at a higher level than an individual University: such as CORE, ACDICT, EA,or ACS. It will be interesting to see what comes out of this.
Today’s keynote was given by Alan Noble, Engineering Director for Google Australia and long-term adjunct at the University of Adelaide, who was mildly delayed by Sydney traffic but this is hardly surprising. (Sorry, Sydney!) Whn asked to talk about Google’s Software Engineering (SE) processes, Alan thought “Wow, where do I began?” Alan describes Google’s processes as “organic” and “changing over time” but no one label can describe an organisation that has over 30,000 employees.
So what does Alan mean by “organic”? Each team in Google is empowered to use the tools and processes that work best for them – there is no one true way (with some caveats). The process encouraged is “launch and iterate” and “release early, release often”, which many of us have seen in practice! You launch a bit, you iterate a bit, so you’re growing it piece by piece. As Alan noted, you might think that sounds random, so how does it work? There are some very important underlying commonalities. In the context of SE, you have an underlying platform and underlying common principles.
Everything is built on Google Three (Edit: actually it’s google3, from Alan’s comment below so I’ll change that from here on) – Google’s third iteration of their production codebase, which also enforces certain approaches to the codebase. At the heart of google3 is something called a package, which encapsulates a group of source files, and this is associated with a build file. Not exciting, but standard. Open Source projects are often outside: Chrome and Android are not in google3. Coming to grips with google3 takes months, and can be frustrating for new hires, who can spend weeks doing code labs to get a feeling for the codebase. It can take months before an engineer can navigate google3 easily. There are common tools that operate on this, but not that many of them and for a loose definition of “common”. There’s more than one source code control system, for example. (As a note, any third party packages used inside Google have the heck audited out of them for security purposes, unsurprisingly.) The source code system used to be Perforce by itself but it’s a highly centralised server architecture that hasn’t scaled for how Google is now. Google has a lot of employees spread around the world and this presents problems. (As a note, Sydney is the 10th largest engineering centre for Google outside of Mountain View.) In response to this scaling problem, Google have tried working with the vendor (which didn’t pan out) and have now started to produce their own source control system. Currently, the two source control systems co-exist while migration takes place – but there’s no mandated move. Teams will move based on their needs.
Another tool is a tracking tool called Buganizer which does more than track bugs. What’s interesting is that there are tools that Google use internally that we will never see, to go along with their tools that are developed for public release.
There’s a really strong emphasis on making sure that the tools have well-defined, well-documented and robust APIs. They want to support customisation, which means documentation is really important if sound extensions and new front ends can be built. By providing a strong API, engineering teams can build a sensible front end for their team – although complete reinvention of the wheel is frowned upon and controlled. Some of the front ends get adopted by other teams, such as the Mondrian UI front-end for Buganizer. Another front end for Google Spreadsheets is Maestro. The API philosophy is carried from the internal tools to the external products.
Google makes heavy use of their own external products that they produce, such as Docs, Spreadsheets and Analytics. (See, dog food, the eating thereof.) This also allows the internal testing of pre-release and just-released products. Google Engineers are slightly allergic to GANTT charts but you can support them by writing an extension to Spreadsheets. There is a spreadsheet called Smartsheet that has been approved for internal use but is not widely used. Scripting over existing tools is far more common.
And now we move onto programming languages. Or should I say that we Go onto programming languages. There are four major languages in use at Google: Java, C++, Python, and Go (the Google language). Alan’s a big fan of Go and recommends it for distributed and concurrent systems. (I’ve used it a bit and it’s quite interesting but I haven’t written enough in it to make much comment.) There are some custom languages as well, including scripting languages for production tasks. Teams can use their own language of choice, although it’s unlikely to be Ruby on Rails anytime soon.
Is letting engineers pick their language the key to Google’s success? Is it the common platform? The common tools? No. The platforms, tools and languages won’t matter if your organisational culture isn’t right. If the soil is toxic, the tree won’t grow. Google is in a highly competitive space and have to be continually innovating and improving or users will go elsewhere. The drive for innovation is the need to keep the users insanely happy. Getting the organisational settings right is essential: how do you foster innovation?
Well, how do they do it? First and foremost, it’s about producing a culture of innovation. The wrong culture and you won’t get interesting or exciting software. Hiring matters a LOT. Try to hire people that are smarter than you, are passionate, are quick learners – look for this when you’re interviewing. Senior people at Google need to have technical skills, yes, but they have to be a cultural fit. Will this person be a great addition to the team? (Culture Fit is actually something they assess for – it’s on the form.) Passion is essential: not just for software but for other things as well. If people are passionate about one thing, something, then you’d expect that this passion would flow over into other things in their lives.
Second ingredient: instead of managing, you’re unmanaging. This is why Alan is able to talk today – he’s hired great people and can leave the office without things falling apart. You need to hire technical managers as well, people who have forgotten their technical skills won’t work at Google if they’re to provide a sounding board and be able to mentor members of the team.
The third aspect is being open to sharing information: share, share, share. The free exchange of information is essential in a collaborative environments, based on trust.
“Info sharing is power, info hoarding is impotence.” (Alan Noble)
The fourth thing is to recognise merit. It’s cool to do geeky things. Success is celebrated generously.
Finally, it’s important to empower teams to be agile and to break big projects into smaller, more manageable things. The unit of work at Google is about 3-4 engineers. Have 8 engineers? That’s two 4 person teams. What about meetings? Is face-to-face still important? Yes, despite all the tech. (I spoke about this recently.) Having a rich conversation is very high bandwidth and when you’re in the same room, body language will tell you if things aren’t going across. The 15 minute “stand up” meeting is a common form of meeting: stand up in the workplace and have a quick discussion, then break. There’s also often a more regular weekly meeting which is held in a “fun” space. Google wants you to be within 150m of coffee, food and fuel at all times to allow you to get what you need to keep going, so weekly meetings will be there. There’s also the project kick-off meeting, where the whole team of 20-30 will come together in order to break it down to autonomous smaller units.
People matter and people drive innovation. Googlers are supposed to adapt to fast-paced change and are encouraged to pursue their passions: taking their interests and applying them in new ways to get products that may excite other people. Another thing that happens is TGIF – which is now on Thursday, rather than Friday, where there is an open Q and A session with the senior people at Google. But you also need strong principles underlying all of this people power.
The common guiding principles that bring it all together need to be well understood and communicated. Here’s Alan’s list of guiding principles (the number varies by speaker, apparently.)
- Focus on the user. This keeps you honest and provides you with a source of innovation. Users may not be articulate what they want but this, of course, is one of our jobs: working out what the user actually wants and working out how many users want a particular feature.
- Start with problems. Problems are a fantastic source of innovation. We want to be solving real, important and big problems. There are problems everywhere!
- Experiment Often. Try things, try a lot of things, work out what works, detect your failures and don’t expose your users to any more failures than you have to.
- Fail Fast. You need to be able to tolerate failure: it’s the flip side of failure. (A brief mention of Google Wave, *sniff*)
- Paying Attention to the Data. Listen to the data to find out what is and what is not working. Don’t survey, don’t hire marketing people, look at the data to find out what people are actually doing!
- Passion. Let engineers find their passion – people are always more productive when they can follow their passion. Google engineers can self-initiate a transfer to encourage them to follow their passion, and there is always the famous Google 20% time.
- Dogfood. Eat your own dogfood! Testing your own product in house and making sure that you want to use it is an essential step.
The Google approach to failure has benefited from the Silicon Valley origins of the company, with the approach to entrepreneurship and failure tolerance. Being associated with a failed start-up is not a bad thing: failure doesn’t have to be permanent. As long as you didn’t lie, cheat or steal, then you’ve gained experience. It’s not making the mistake, it’s how you recover from it and how you carry yourself through that process (hence being ethical even as the company is winding down).
To wind it all up, Google doesn’t have standard SE processes across the company: they focus on getting their organisation culture right with common principles that foster innovation. People want to do exciting things and follow new ideas so every team is empowered to make their own choices, select their own tools and processes. Launch, iterate, get it out, and don’t hold it back. Grow your software like a tree rather than dropping a monolith. Did it work? No? Wind it back. Yes? Build on it! Take the big bets sometimes because some big problems need big leaps forward: the moon shot is a part of the Google culture.
Embrace failure, learn from your mistakes and then move on.
The Australasian Software Engineering Conference has been around for 23 years and, while there have been previous efforts to add more focus on education, this year we’re very pleased to have a full day on Education on Wednesday, the 9th of April. (Full disclosure: I’m the Chair of the program committee for the Education track. This is self-advertising of a sort.) The speakers include a number of exciting software engineering education researchers and practitioners, including Dr Claudia Szabo, who recently won the SIGCSE Best Paper Award for a paper in software engineering and student projects.
Here’s the invitation from the conference chair, Professor Alan Fekete – please pass this on as far as you can!:
- Keynote by a leader of SE research, Prof Gail Murphy (UBC, Canada) on Getting to Flow in Software Development.
- Keynote by Alan Noble (Google) on Innovation at Google.
- Sessions on Testing, Software Ecosystems, Requirements, Architecture, Tools, etc, with speakers from around Australia and overseas, from universities and industry, that bring a wide range of perspectives on software development.
- An entire day (Wed April 9) focused on SE Education, including keynote by Jean-Michel Lemieux (Atlassian) on Teaching Gap: Where’s the Product Gene?
Regrettably, despite best efforts, I was a bit late getting back from the lunch and I missed the opening session, so my apologies to Andres Neyem, Jose Benedetto and Andres Chacon, the authors of the first paper. From the discussion I heard, their course sounds interesting so I have to read their paper!
The next paper was “Selecting Open Source Software Projects to Teach Software Engineering” presented by Robert McCartney from University of Connecticut. The overview is why would we do this, the characteristics of the students, the projects and the course, finding good protects, what we found, how well it worked and what the conclusions were.
In terms of motivation, most of their SE course is in project work. The current project approach emphasises generative aspects. However, in most of SE, the effort involves maintenance and evolution. (Industry SE’s regularly tweak and tune, rather than build from the bottom.) The authors wanted to change focus to software maintenance and evolution, have the students working on an existing system, understanding it, adding enhancements, implementing, testing and documenting their changes. But if you’re going to do this, where do you get code from?
There are a lot of open source projects, available on0line, in a variety of domains and languages and at different stages of development. There should* be a project that fits every group. (*should not necessarily valid in this Universe.) The students are not actually being embedded in the open source community, the team is forking the code and not planning to reintegrate it. The students themselves are in 2nd and 3rd year, with courses in OO and DS in Java, some experience with UML diagrams and Eclipse.
For each team of students, they get to pick a project from a set, try to understand the code, propose enhancements, describe and document all o their plans, build their enhancements and present the results back. This happens over about 14 weeks. The language is Java and the code size has to be challenging but not impossible (so about 10K lines). The build time had to fit into a day or two of reasonable effort (which seems a little low to me – NF). Ideally, it should be a team-based project, where multiple developed could work in parallel. An initial look at the open source repositories on these criteria revealed a lot of issues: not many Java programs around 10K but Sourceforge showed promise. Interestingly, there were very few multi-developer projects around 10K lines. Choosing candidate projects located about 1000 candidates, where 200 actually met the initial size criterion. Having selected some, they added more criteria: had to be cool, recent, well documented, modular and have capacity to be built (no missing jar files, which turned out to be a big problem). Final number of projects: 19, size range 5.2-11 k lines.
That’s not a great figure. The takeaway? If you’re going to try and find projects for students, it’s going to take a while and the final yield is about 2%. Woo. The class ended up picking 16 projects and were able to comprehend the code (with staff help). Most of the enhancements, interestingly, involved GUIs. (Thats not so great, in my opinion, I’d always prefer to see functional additions first and shiny second.)
In concluding, Robert said that it’s possible to find OSS projects but it’s a lot of work. A search capability for OSS repositories would be really nice. Oh – now he’s talking about something else. Here it comes!
Small projects are not built and set up to the same standard as larger projects. They are harder to build, less-structured and lower quality documentation, most likely because it’s one person building it and they don’t notice the omissions. Thes second observation is that running more projects is harder for the staff. The lab supervisor ends up getting hammered. The response in later offerings was to offer fewer but larger projects (better design and well documented) and the lab supervisor can get away with learning fewer projects. On the next offering, they increased the project size (40-100K lines), gave the students the build information that was required (it’s frustrating without being amazingly educational). Overall, even with the same projects, teams produced different enhancements but with a lot less stress on the lab instructor.
Rather unfortunately, I had to duck out so I didn’t see Claudia’s final talk! I’ll write it up as a separate post later. (Claudia, you should probably re-present it at home. 🙂 )
It’s nearly the end of semester and that means that a lot of projects are coming to fruition – or, in a few cases, are still on fire as people run around desperately trying to put them out. I wrote a while about seeing Fred Brooks at a conference (SIGCSE) and his keynote on building student projects that work. The first four of his eleven basic guidelines were:
- Have real projects for real clients.
- Groups of 3-5.
- Have lots of project choices
- Groups must be allowed to fail.
We’ve done this for some time in our fourth year Software Engineering option but, as part of a “Dammit, we’re Computer Science, people should be coming to ask about getting CS projects done” initiative, we’ve now changed our third year SE Group Project offering from a parallel version of an existing project to real projects for real clients, although I must confess that I have acted as a proxy in some of them. However, the client need is real, the brief is real, there are a lot of projects on the go and the projects are so large and complex that:
- Failure is an option.
- Groups have to work out which part they will be able to achieve in the 12 weeks that they have.
For the most part, this approach has been a resounding success. The groups have developed their team maturity faster, they have delivered useful and evolving prototypes, they have started to develop entire tool suites and solve quite complex side problems because they’ve run across areas that no-one else is working in and, most of all, the pride that they are taking in their work is evident. We have lit the blue touch paper and some of these students are skyrocketing upwards. However, let me not lose sight of one our biggest objectives, that we be confident that these students will be able to work with clients. In the vast majority of cases, I am very happy to say that I am confident that these students can make a useful, practical and informed contribution to a software engineering project – and they still have another year of projects and development to go.
The freedom that comes with being open with a client about the possibility of failure cannot be overvalued. This gives both you and the client a clear understanding of what is involved- we do not need to shield the students, nor does the client have to worry about how their satisfaction with software will influence things. We scaffold carefully but we have to allow for the full range of outcomes. We, of course, expect the vast majority of projects to succeed but this experience will not be authentic unless we start to pull away the scaffolding over time and see how the students stand by themselves. We are not, by any stretch, leaving these students in the wilderness. I’m fulfilling several roles here: proxying for some clients, sharing systems knowledge, giving advice, mentoring and, every so often, giving a well-needed hairy eyeball to a bad idea or practice. There is also the main project manager and supervisor who is working a very busy week to keep track of all of these groups and provide all of what I am and much, much more. But, despite this, sometimes we just have to leave the students to themselves and it will, almost always, dawn on them that problem solving requires them to solve the problem.
I’m really pleased to see this actually working because it started as a brainstorm of my “Why aren’t we being asked to get involved in more local software projects” question and bouncing it off the main project supervisor, who was desperate for more authentic and diverse software projects. Here is a distillation of our experience so far:
- The students are taking more ownership of the projects.
- The students are producing a lot of high quality work, using aggressive prototyping and regular consultation, staged across the whole development time.
- The students are responsive and open to criticism.
- The students have a better understanding of Software Engineering as a discipline and a practice.
- The students are proud of what they have achieved.
None of this should come as much of a surprise but, in a 25,000+ person University, there are a lot of little software projects on the 3-person team 12 month scale, which are perfect for two half-year project slots because students have to design for the whole and then decide which parts to implement. We hope to give these projects back to them (or similar groups) for further development in the future because that is the way of many, many software engineers: the completion, extension and refactoring of other people’s codebases. (Something most students don’t realise is that it only takes a very short time for a codebase you knew like the back of your hand to resemble the product of alien invaders.)
I am quietly confident, and hopeful, that this bodes well for our Software Engineers and that we still start to seem them all closely bunched towards the high achieving side of the spectrum in terms of their ability to practice. We’re planning to keep running this in the future because the early results have been so promising. I suppose the only problem now is that I have to go and find a huge number of new projects for people to start on for 2013.
As problems go, I can certainly live with that one!
In the Thursday keynote, Professor Brooks discussed a couple of project approaches that he thought were useful, based on his extensive experience. Once again, if you’re not in ICT, don’t switch off – I’m sure that there’s something that you can use if you want to put projects into your courses. Long-term group projects are very challenging and, while you find them everywhere, that’s no guarantee that they’re being managed properly. I’ll introduce Professor Brooks points and then finish with a brief discussion on the use of projects in the curriculum.
Firstly, Brooks described a course that you might find in a computer architecture course. The key aspect of this project is that modern computer architecture is very complex and, in many ways, fully realistic general purpose machines are well beyond the scope of time and ability that we have until very late undergraduate study. Brooks works with a special-purpose unit but this drives other requirements, as we’ll see. Fred’s guidelines for this kind of project are:
- Have milestones with early delivery.
Students must provide a detailed application description which is the most precise statement that the students can manage. A precise guess is considered better here than a vague fact, because the explicit assumption can be questioned and corrected, where handwaving may leave holes in the specification that will need to be fixed later. Students should be aware of how sensitive the application is to each assumption – this allows people to invest effort accordingly. The special-purpose nature of the architecture that they’re constructing means that the application description has to be very, very accurate or you risk building the wrong machine.
Programming Manual (End of the first month as a draft)
Another early deliverable is a programming manual – for a piece of software that hasn’t been written yet. Students are encouraged to put something specific down because, even if it’s wrong, it encourages thought and an early precision of thought.
- Then the manual is intensely critiqued – students get the chance to re-do it.
- The actual project is then handed in well before the final days of semester.
- Once again the complete project goes through a very intense critique.
- Students get the chance to incorporate the changes from the critique. Students will pay attention to the critique because it is criticism on a live document where they can act to improve their performance.
The next project described is a classic Software Engineering project – team-based software production using strong SE principles. This is a typical project found in CS at the University level but is time-intensive to manage and easy to get wrong. Fred shared his ideas on how it could be done well, based on running it over 22 years since 1966. Here are his thoughts:
- You should have real projects for real clients.
Advertise on the web for software that can be achieved by 3-5 people during a single semester, which would be useful BUT (and it’s an important BUT) you can live without. There must be the possibility that the students can fail, which means that clients have to be ready to get nothing, after having invested meeting time throughout the project.
- Teams should be 3-5, ideally 4.
With 3 people you tend to get two against one. With five, things can get too diffuse in terms of role allocation. Four is, according to Fred, just right.
- There should be lots of project choices, to allow teams choice and they can provide a selection of those that they want.
- Teams must be allowed to fail.
Not every team will fail, or needs to fail, but students need to know that it’s possible.
- Roles should be separated.
Get clear role separations and stick to them. One will look after the schedule, using the pitchfork of motivation, obtaining resources and handling management one level up. One will be chief designer of technical content. Other jobs will be split out but it should be considered a full-time job.
- Get the client requirements and get them right.
The client generally doesn’t really know what they want. You need to talk to them and refine their requirements over time. Build a prototype because it allows someone to say “That’s not what I want!” Invest time early to get these requirements right!
- Meet the teams weekly.
Weekly coaching is labour intensive and is mostly made up of listening, coaching and offering suggestions – but it takes time. Meeting each week makes something happen each week. When a student explains – they are going to have to think.
- Early deliverable to clients, with feedback.
Deadlines make things happen.
- Get something (anything) running early.
The joy of getting anything running is a spur to further success. It boosts morale and increases effort. Whatever you build can be simple but it should have built-in stubs or points where the extension to complexity can easily occur . You don’t want to have to completely reengineer at every iteration!
- Make the students present publicly.
Software Engineers have to be able to communicate what they are doing, what they have done and what they are planning to do – to their bosses, to their clients, to their staff. It’s a vital skill in the industry.
- Final grade is composed of a Team Grade (relatively easy to assess) AND an Individual Grade (harder)
Don’t multiple one by the other! If effort has been expended, some sort of mark should result. The Team Grade can come from the documentation, the presentation and an assessment of functionality – time consuming but relatively easy. The Individual Grade has to be fair to everyone and either you or the group may give a false indication of a person’s value. Have an idea of how you think everyone is going and then compare that to the group’s impression – they’ll often be the same. Fred suggested giving everyone 10 points that they allocated to everyone ELSE in the group. In his experience, these tallies usually agreed with his impression – except on the rare occasion when he had been fooled by a “mighty fast talker”
This is a pretty demanding list. How do you do tasks for people at the risk of wasting their time for six months? If failure is possible, then failure is inevitable at some stage and it’s always going to hurt to some extent. A project is going to be a deep drilling exercise and, by its nature, cannot be the only thing that students do because they’ll miss out on essential breadth. But the above suggestions will help to make sure that, when the students do go drilling, they have a reasonable chance of striking oil.