Management and Leadership Archives - The Oasis Digital Blog

Angular for Architects – preview/beta class, Jan 2021

First we worked for years on numerous enterprise Angular projects. Then we spent months organizing the knowledge of our experts. The result: Angular for Architects, now available from Oasis Digital.

This class is about both the coding aspects of Angular architecture, and also the decisions, patterns, costs, and constraints that drive architectural decisions.

Early access / Beta test class

To prepare and validate the curriculum for Angular for Architects, we are running a special beta-test version of the class. To show appreciation for attendees willing to jump in at this stage, the price is cut by half.

The first such Beta test is in January. Depending on how it goes we run a second “beta”, or proceed to standard pricing.

Who Should Attend?

Decision makers responsible for large or complex Angular projects
Angular tech leads and project managers
Application and system architects
Teams looking for a shared understanding of Angular architecture and practices

Thinking hard about a project launch

Here at Oasis Digital, we are always agile, and depending on the project needs, sometimes use Agile (in the “capital A” sense) processes extensively. Yet regardless of agility, iterations, steering, and so on, the planning and decisions made at the beginning (and in the early months) of a project often have profound and very difficult to change consequences later.

Therefore, while we would never argue for the straw-man Waterfall, we aim to think very hard about a project at the beginning.

Continue reading Thinking hard about a project launch

Oasis Digital developer hiring process

Candidates keep asking: what is the process to be hired at Oasis Digital as a software developer?

Our process is solid, realistic, and strikes a good balance between speed and depth. Yet merely knowing what the process is, isn’t much competitive advantage, there’s no reason to keep it secret. Good results flow from the execution, not the checklist.

As of 2018, here is the typical Oasis Digital hiring “workflow”; sometimes it varies for special cases, people with whom we already have a substantial connection. It’s best to think of this as a kind of “funnel”. At each stage, we are looking for signs that the candidate would perform well and be great addition to our team – and trying to show strong candidates that we offer them an opportunity to thrive.

Initial contact or awareness. Perhaps they see a job post somewhere, or someone refers them to us. Ideally they have a chance to watch a short video about the job and about working at Oasis Digital. Usually we receive a resume (via a tracking system, like everyone else – so that we don’t lose track of any). Of those, some catch our eye. Those move on to…
We have an initial, short conversation/interview about the candidate’s experience, current situation, what they’re looking for in their next job, qualifications, etc. We have this conversations over a video chat, to provide the candidate the maximum “bandwidth” opportunity to make a good impression about these things. A portion of the candidates move on to…
A longer discussion. This discussion again is ideally over a video chat, and often involves more than one of us at Oasis Digital. If the candidate already happens to be in St. Louis, sometimes we meet in our office or over lunch; but video chat is actually “good enough” even for local candidates, and that sometimes can be scheduled more easily or promptly. Of these candidates, a portion move on to…
Our real interview with a software development candidate is to spend time coding together. Ideally this is in-person in our office; although for an out-of-town candidate it’s possible to do this over a screen sharing session. We try to spend at least an hour on this, sometimes several. Working on some code together is by far the most effective way to understand where a candidate is in their development mastery. It is much more effective, and faster, than the sort of “take-home sample programming assignment” that has become popular in recent years. If this goes well and we are favorably impressed, a candidate might move on to…
A deeper, more traditional “HR style” interview, where we talk about the candidate’s experiences, strengths, weaknesses, goals, and so on in depth. Will the person the person strengthen our team, and reinforce our values? Are our benefits and compensation attractive? Can an agreeable salary be worked out? If all that goes well, the final stage is…
There is a background check process; our customers often require that developers with access to their materials have a clean background check. Assuming nothing negative pops up…
Successful hire – onboarding begins.

From writing all that, wow, it sounds like a lot! In the best case, it can be executed in a few days of elapsed time, although usually there is not such a rush. Our process is intended to be a less onerous time commitment for everyone involved – yet still provide ample opportunity to get to know each other – compared to what some larger companies go through.

Update (2021):

For many positions we’ve streamlined and improved even further from the 2018 description above. Our process focuses on seeing candidates in action. We hire on demonstrable technical proficiency or potential, not on the ability to endure lengthy traditional interview questioning. The process:

Job post and informational video provide candidates information before interviewing.
Interview 1: discuss some code, and the candidate codes a bit. 30 minutes or less.
Interview 2: discuss more code, candidate codes more. Discuss the job more. 30-45 minutes.
For some roles or candidates, additional interviews are needed.
Offer, hire, start.
Onboarding, learning boost, and mentorship process begins.

(Of course there is variance on the length and use of the interviews, depending on details of each position.)

Software Demonstration and Project Status: Use Video

At Oasis Digital, custom software projects work at various cadences: weekly, biweekly, or sometimes in variable-length cycles. Regardless, at each interval or milestone it’s important to deliver a comprehensive demonstration and status update for our project customer.

Live demonstrations considered harmful

Unfortunately, the most obvious way to deliver demos and status updates does not work very well:

Perform a live, high-stakes demo – Murphy’s Law applies. Systems break during a live demo.
Freshly, the first time, making it up as you go along.
Think about project status only when asked.
Seen only by stakeholders who are able to attend the meeting – often a small subset of the people who care about the demonstration and status

It seems silly to even describe these things, but I’ve seen this poor approach as standard across much of the software development world.

Effective software demonstration and project status delivery

We have refined a much better way to deliver software demonstrations and project status updates. The short answer is, “make a video”. The long answer is to make a comprehensive demonstration and project status update video, deliver it to all interested stakeholders, then have a meeting to discuss the demonstration and states. This results in an easier, deeper, and more thoughtful meeting and also serves stakeholders who can’t attend.

Every demo/status video serves a number of purposes and audiences; so it’s important to cover topics of interest to all kinds of stakeholders, not only the stakeholders most able to attend. At the same time, we don’t recommend creating multiple videos for multiple audiences; that is an unsustainable pace of content production, it takes too much time away from the core work of creating quality software.

Make one medium-length video per cycle (week/biweekly/whatever) to address:

Demonstration
Project progress summary
Upcoming work
Key open questions
Interesting or important technical details

In this way, each video is of value to both “local” stakeholders (the specific customer team managing the project from day to day) and broader stakeholders across a customer organization.

Next, the nitty-gritty of what goes in to a such a video and how to make it. The agenda should go roughly in this order.

Introduction / Title Slide

Files (including video files_ tend to be misclassified, mislabeled, and misplaced. Someone might open up your demo/status video and not know anything about what’s inside. Therefore, always start with a title slide. That slide should include:

Name of the project
Name and logo of the customer organization the project is for
Date (sometimes just month and year, for slower-paced projects)
Name and title of the person making this video (speaking)
Name, URL, and logo of the company working on the software (for us, “Oasis Digital”)

While the title slide is visible, briefly introduce yourself. You have only a few seconds of viewer attention; the slide and your introduction should last 10 seconds or at most 15, before you cut to the next section.

Still video is a waste of bandwidth, and drives viewers away. Never let the video stay still while you talk for more than a few seconds.

Demonstration

After that brief introduction, jump right into the demonstration. If you learn only one thing about effective demonstrations, here it is:

Get to the payoff fast.

Don’t wander through a long buildup in which only the most dedicated viewer can reach the important part. Show the payoff, the most important bit, within the first few minutes. Then, go back and explain the rest of the story to give a comprehensive demonstration of use cases.

Your demonstration should bring the viewer through one or more use cases relevant to the work underway. Through these use cases, remind the viewer of the overall purpose and functionality of the software project, and point out the new and changes parts, showing progress.

Demonstrations tend to go wrong, or to waste a lot of time, by default. To produce a quality demonstration:

Practice.

Yes, practice. Jot down a terse outline of what you plan to demonstrate, and practice it a couple of times (with the video recorder running) to get familiar with exactly what will happen. If you see anything urgent to fix while making these practice attempts, you might stop and fix it right then. Then once your practice demo goes well, record the real demo.

In a demonstration of a user interface, text and UI elements be readable. We get the best results by sizing the software and recording a “stage” of 1280×720 pixels. A video that size can easily be played back in a non-full-screen window on a typical computer. If your software under demonstration can’t be used at the small window size (i.e. screens that really only work at 1920 resolution), make sure to boost font sizes.

(Some stakeholders, including quite important ones, might only have an opportunity to watch your demonstration video on their cell phone! Think about font and other element sizes accordingly.)

Lastly, create a demonstration you can be proud of. If your demonstration went badly, discard that recording and do it over. If you have been keeping your demonstrations tight, it won’t cost much time if you occasionally have to discard and try again. If your demonstration is so long that starting over is unthinkable, make shorter demonstrations more often.

Project status and management update

After demonstrating progress on the software, provide an update on the project. We heartily recommend the following order:

Review at what has been done since the last update; positive progress
Preview at what is coming up next; anticipated progress
Discuss upcoming key questions or issues that could delay or prevent progress

Point 1 is especially important and easily overlooked. We have had projects which were objectively going extremely well: delivering a pile of valuable functionality every week for years on end. But looking back, it’s easy to get in a meeting rut – the tone of a project can be ruined by an inadvertent meeting focus on only what is going wrong. Therefore, before discussing what is coming up in what might go wrong, always briefly summarize what has gone well.

The details of how to show status and upcoming work vary by your methodology and toolset. We most often use Jira, and to talk about these things by scrolling, clicking, and talking about an Agile Board in Jira, often supplemented by a Dashboard. You can do the same with other software, or even with a manual project management system.

Obstacles and questions

Having shown visible progress in the demonstration then talked about project status, you now have the viewers’ attention to deal with challenges. Most likely any obstacles or questions are connected to issues in your project management tracking system; so click back through the relevant ones and discuss these things. Make sure to show the relevant part of the software and the relevant bits in the project management software. (Reminder – never more than a few seconds of still video with just a person talking.)

We have found that our recap of obstacles and questions on video, can be very helpful to our customers representatives. They can show the video to other people in their organization who might be able to help with the obstacle. They can listen as well as read – some people enjoyed listening more than reading. They can arrive for a live meeting, already having thought about the questions and ready to answer.

Technical

The last major section of a demo/status video should dig into any interesting or important technical aspects. Here is the chance to show an IDE or source control tool instead of just the running software or Jira board. Most likely the technical bits worth discussing will concern either recently completed features or features coming up shortly, but sometimes a broader topic might warrant attention.

In our experience, digging into the important technical details can also support rapport and credibility with more kinds of stakeholders. Every organization contains a mix of people most responsive to project management, and others most responsive to technical depth.

Closing

As your video ends, flip back to the title slide and thank the viewer for their attention. As hard as you may have worked (more than the length of the resulting video, sometimes much more), your viewer has also dedicated their limited time to watch. Thank them.

Video and audio production tips

Surprisingly, often the most important aspect of video production is audio. You need a quiet room and a decent quality microphone. The former can be hard to achieve in a busy crowded workspace, but it’s worth the effort. Hide in a conference room. Get a coworker to stand guard at the door.

An amply good microphone costs well under $100. We’ve had good results with various types of headsets (but read more about that later), with Blue Snowball microphones, and with a popular Audio Technica model. All of these are quite inexpensive. Any of them are vastly better than trying to use a laptop’s built in microphone.

Next, screen video. You’ll need appropriate screen video recording software, and you will need to master its configuration. We recommend:

ScreenFlow, on OSX
OBS, on Windows

Video is about more than just the screen though. If you’ve made it this far into this post, you are ready for perhaps the most important advice of all:

Show your face

A demo/status video is not only about information delivery, it is also about personal connection. Humans are hardwired to connect with other humans while looking at their face. Therefore your face should be visible in the video. Both of the software packages above can easily show your face in a corner of the screen. Do so. (Back to the headset idea – a headset can provide excellent audio pick up, but then you will be wearing a headset in the video. Therefore the headset is not the best solution for this use.)

Video of your face means you need a camera. Most laptops have an amply good camera built-in (but sit your laptop on a stack of books or something handy – so that the laptop camera is not looking up your nose!). Or add an external webcam (< $100) atop an external monitor for better results.

Speaking of cameras, cameras detect light. Rearrange the lighting in your space (or add a $30 lamp) to get some light on the front of your face during your video recording. Your eyes should not be in shadow.

If your recording software supports it (both of the above mentioned packages do), add a “bug”, a term of art for a partially transparent logo in the corner of the screen. For example, if you decide to put your face in the upper right, then the lower left of the screen could contain your company logo at 50% transparency. A video is a branding opportunity in addition to an information communication opportunity.

Finally, reread the advice earlier in the demonstration section, about font and screen recording sizes. Then read them again. 🙂

Feedback wanted

We have worked out the advice here over years of various attempts to communicate demonstration and status information well. But we surely have much more to learn, and appreciate any feedback readers send. Thanks for getting this far, and good luck in your demonstrations and meetings.

The Cobbler’s Kids

The old saying about the cobbler’s kids that have no shoes is as true in concept now as it was a millenia ago. At Oasis Digital, where we find great solutions to increase the success of our customers, we have been so focused on those projects that we find ourselves lacking our marketing shoes. Our marketing efforts have been tertiary at best.

A few years ago we realized the need to develop our brand, a few months ago we started moving forward, and a few weeks ago we sat down and started the process with our team. I asked them to articulate what we are really good at, what they were proud of. The list was broad, and spoke to their understanding of the value they bring to our clients. Here is the list:

We don’t just build what the customer describes, we address needs in a well-thought out manner. We creatively solve problems, not just execute.
What we build can last (longevity). and scale
Our teams communicate and collaborate
Challenges/problems are shared in the team
Our tech stack stays fresh
We teach about what we use
High quality, comprehensive design documents that hit the mark the first time.
Continuous learning/continuous improvement professionally
We can bridge the gap between techies and lay people
Our team can communicate effectively
Always look to improve, solve the problem with less code
We push for regular delivery, to finish items, not have long-standing open work items

This is the first bit, what we do well. The further question is how do we do these things. Very often, how you do things communicates your value to your customers. For example, people find our training very valuable because it is intensely workshop based, and taught by an actual practitioner of the craft, not a professional teacher.

We build high quality software
We empower our customers to prosper
We leave customers and projects better than we found them

We are a values based organization, so the “what” and the “how” are not the full answer. When you answer the “why” you find the values that motivate your work. The answer I came to was two-fold:

We love to solve problems
We love to help people

The wording will change over time but our core motivator is solving hard problems that have value. We really enjoy that process. Adding value, helping people and businesses to be successful, those are solid values that we believe will resonate with the right kinds of customers.

I love the powerful words pushed forward by the team. They are full of meaning and demonstrate the consistency through the team of our values.

love, empower, build, communicate, help, teach, improve, finish, learning, effective, collaborate

I cannot wait to have these ideas permeate our web presence and our marketing communications. If we can push this to conclusion I believe we will finally have a nice pair of shoes!

JIRA Case Study: Nested Workflows

Using custom issue types and multiple nested workflows to bring business management processes into a project without disrupting the core workflow.

Last month I had the pleasure of teaching a private JIRA Boot Camp at a national corporation on the East Coast. They had been using JIRA for a while, and had achieved a level of success in within their development team. They knew JIRA had the ability to play a larger role, but they were struggling to really integrate it into the business. They asked if I could come out and go through my normal curriculum but with an eye on their particular situation.

Working with the Director of IT, we decided to really push hard to complete the curriculum in two days and spend the third heavily focused on their internal challenges and their production environment. By the end of the day it was really clear this had been a wise choice. They were picking up the main curriculum very well, and they could see how to move development based items through the workflow. They were struggling with how to manage the business-related processes that precipitated and followed the software development process. Like most people, they understood JIRA could be so much more than an issue tracker, they just needed a little guidance to make it happen.

As we went through the workflow exercises in the curriculum, the problem crystallized. In their organization, initiatives would be proposed by various leaders of groups throughout the company. Those initiatives would go through an assessment, research, and approval process before any development occurred. They needed to track these initiatives so they knew what was coming, but kept mixing them into the development workflow. After we covered custom issue types, I approached the solution with them. They needed to nest a development workflow inside a workflow to track initiatives. This could be done with custom issue types and advanced workflow configuration.

First we white boarded the initiative workflow both before and after development occurred. The results are shown below.

The process for the initiatives was fairly complex both before and after development. The entire development process was represented by a “development” status for the initiative. Important truth, the business process “around” development work is often far more complex than the development process itself.

After this we nailed down a straightforward workflow for the development process, represented in the next image. The essential process became crystal clear to them once we removed the distraction of the messy process surrounding it. I needed to coach them very little once the distractions were removed.

The answer to the overall problem was to allow the original initiative to be created, researched and run through an approval process. This initiative then needed to be tied to the development work while it was being completed. Once this phase was completed, there was a well-defined business process that needed to be completed for the whole initiative.

The next challenge was how to implement this in JIRA. The first step was to define the two separate workflows and lay out the statuses and transitions of each. Even though there were some possibilities of sharing statuses between the workflows, we were very careful not to do so. I have learned to isolate workflows that have different purposes. I have written about this previously, here. Mixing the purpose of a workflow includes using a status from a different workflow that may share a name. If the meaning is different in any way then a status should not be shared.

We then created the custom issue types that would be used by each workflow. There were multiple custom issue types needed for each workflow. We created multiple custom issue types for each workflow, then negotiated the transition between the issue types and workflows in a way that fit the organization.

An initiative would ride through its process until it was approved. It was then transitioned to the development status. The initiative was then assigned a label and the development items were created and tagged with that label. The initiative was not allowed to transition out of development until all the items with that label were resolved. The development items then make their way through the process to completion, thus allowing the initiative to move forward to the review, field testing, and deployment stages in the first workflow.

Another bonus of this approach was reporting. An agile board could be created for each initiative, allowing the stakeholder to monitor progress of his project. Another agile board could be created to track all the initiatives, another for initiatives by department, another for development tasks by developer.

The net result was that a very complex, opaque process made manageable and transparent by utilizing custom issue types, separate workflows and advanced workflow configuration to nest the two workflows together. Yet another example of how powerful JIRA is, and how strategic use of its flexibility can improve organizational efficiency.

Leaders vs. Entropy

The other day my wife made a funny word association looking at our company’s timesheets. She commented that the category “Misc Management” looked an awful lot like “Mismanagement”. This got me thinking. I should clarify that what I am writing has nothing to do with that particular use of Misc Management, it is an appropriate catch-all category. What it did is point my focus at a common hazard that threatens leaders.

Another very important distinction for the purposes of this article. I am writing this for leaders specifically, not managers. They are very different and valuable roles. If your job is to set direction for a family, group, or organization then this article is for you.

Just like any other highly effective role, successful leaders are dogged by the temptation to be complacent and settle once they achieve a goal. Common signs of this are:

Constantly focusing on what has been achieved
Your time is filled with “running” the show
You start managing instead of leading
Defining yourself in terms of what you manage

We have to remember the 2nd law of thermodynamics, which I believe to have spiritual, social, relational, and political implications in addition to physical properties.

Second Law of Thermodynamics

The entropy of an isolated system never decreases, because isolated systems spontaneously evolve toward thermodynamic equilibrium.

In Lay terms:

There is a tendency for all matter, systems and energy to decline into a state of inert uniformity and decay.

A Layperson’s Definition of Entropy

Entropy is a measure of randomness/order/disorder

The fallacy that we ever “arrive” as people permeates our society. We falsely believe that if we have a certain job, or reach a certain goal we will have happiness. The irony is that the second law of thermodynamics applies to us just as much as it applies to inanimate systems. We need to continue to grow, continue to learn, continue to develop in order to avoid degradation.

Look at physical fitness. Once someone achieves a high level of fitness, what happens if they stop exercising and sit for a month. It seems obvious that the person will lose that edge. There will still be a high level of fitness but it will not be the same. If the sitting continues for six more months the person will hardly be recognizable. Why would any other aspect of ourselves be different?

If I do not spend time in prayer, my relationship with God deteriorates. If I spend less time focusing on maintenance of my home, it deteriorates. If I spend less time focused on the goals and direction of my business, it deteriorates. I could continue with dozens of other examples.

Leaders can never afford to stop looking towards the future. In my pursuit of being a good leader, I will never arrive. I will always need to labor over the next hurdle and look into the horizon. If I do not, I simply stop being a leader and entropy takes over.

Look at those leaders that you follow. Are they focused on a future objective? Do they focus on what has already occurred? Any person who is trying to lead hits periods of doubt, whether they show it or not. If you see a leader beginning to slide into the grip of entropy, provide encouragement. Often a naturally gifted leader only needs a small bump to get back on track. If someone you are following has been off track for some time, you should probably reconsider your commitment to them. The easiest place to apply this is politics. Focus on candidates with a vision for the future, not those that just pick at their opponents.

If you are a leader, challenge yourself regularly about your future direction. Most people are expected to lead in some aspect of their lives. By keeping a vision for what you are leading today, you will be more likely to become the type of person everyone wants to follow. Do not be afraid of the future, find the vision for something better and set a course to the next horizon.

Traditional Project Management is Dead

The discipline just does not know it yet.

When I speak of traditional project management, I mean a very rigid approach where the end is predetermined, with a level of specificity to allow for detailed estimates, and schedules. This can be the construction of a building, or the management of an election campaign where massive change is not allowed. The Project Management Institute (PMI) defines project management as:

“the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”

I prefer this, more organic definition:

“Project management is the discipline of planning, organizing, understanding, motivating, influencing, and directing resources to achieve a set of goals.”

I am continuously intrigued by the application of principles across different aspects of our lives. As people we tend to want to segment our lives and decision-making when often the exact opposite is what we need. Lessons we learn in one aspect of our life often are directly applicable to others. This article on the psychology of our personal development is a good example. You can read it here.

As people we can often see how far we have come looking into the past. We see growth, we see our failures, we puff up at our successes, yet we hit a wall looking into the future. “The end of history illusion” is very real and very applicable to the far reaches of our lives. This even applies to specific professions.

I think this phenomenon helps articulate how I feel about a number of technologies. I often receive a quizzical look from people when I suggest that some company or system is a “dead man walking”. My assessment is sometimes incorrect, but more often accurate. (Blackberry – correct, Cisco – wrong, Novell – correct, Microsoft – we will see)

My intent in this article is to apply all of this thought specifically to project management. I have a number of friends who are project managers or construction managers across a number of fields. New technology, manufacturing realities, and a wavering economy are a wrecking ball to the traditional task-based, progress-tracking, Gantt-chart-toting PM.

Traditional project management is based on the premise that work can be estimated. This is the foundation of projects everywhere and a natural expectation on the part of those paying for the project. The disruptive reality is that estimating is far less accurate today than it was ten years ago for many kinds of work. The pace of technological and social advancement means that we are not estimating a predictable set of acts by a predictable workforce. If we are truly honest with ourselves, I think we will see that it is impractical to try to hone estimates very closely at all. Our society is changing even more quickly than in the past. In order to encompass all the variables in an estimate today you have to increase cost and schedule estimates to astronomical heights. This has been true to a degree throughout my career, but there are fewer companies/people today who are willing to pay a premium for something to be built predictably.

Technology

Advancements in materials are impacting every corner of our world. From LED light bulbs to durable paints to large flat screens you can lift with a couple of fingers, things are different every single quarter. The changes blow gaping holes in traditional practices and understandings. I would question any project that is not impacted by new and challenging technologies. We cannot live in the past. This specifically damages estimating, the idea that you can predict what will happen next is preposterous.

Manufacturing

Large scale manufacturing at a component level has severely declined in the US. Sure, we assemble parts manufactured in other countries into a finished product, but we are turning raw materials into finished goods at far lower rates than in the past. This impacts the choices and the quality of materials dramatically. Products at the quality level we need for certain applications are 3x or 5x what they are for the common part. A simple explanation can be seen in the steel industry. First Japanese steel starting eroding the American steel industry. It was well known and accepted that the quality was different. Now, our steel industry is almost gone and most steel comes from China. If you need very specialized steel with certain properties it is extremely expensive. In the past, it was only marginally more expensive because it was manufactured up the road, not around the world. On the other end of the spectrum, cottage manufacturing is on the verge of booming with advancements in 3d printing et al. These techs yield highly specialized parts at low production numbers for a fraction of the traditional cost. How can traditional approaches adapt to these conflicting realities?

The Economy

Money is tight, budgets are stretched. Not much stupid money floating around these days. Not much more needs to be said…

Conclusion

I believe the Agile processes pioneered in the software industry hold the answer. Many of these concepts are also defined in Total Quality Management systems and the Baldrige Continuous Improvement model. Unfortunately, none of these and the iterative cycle they promote have ever really been adopted across the project management industry. The barrier to doing so is the simple fact that many project managers are not deep experts of their industry, they simply manage schedules and compile information provided by others. As a group, project managers need to engage in their profession. I believe that project managers in the future will need to have a greater understanding and take a larger role in the active delivery of complex projects.

I am excited for the changes that are coming. For those that embrace the change occurring around them the future is quite bright. For those that want to cling to the past, they will find themselves on the outside looking in at projects they do not understand. To bring this full circle we need to visualize where our particular industry will be in ten years and build those skills. I would have expected people to realize the importance of this looking back at the impact of computers etc. I guess “The end of history” illusion is powerful in all aspects of our lives.

Code Reviews – Use a gate, not a drive-by

Does your team / project use code reviews? If not, I suggest starting today. There are countless resources online about how and why to do code reviews; there are numerous code review tools, open source and commercial.

Who should review code? A great question, perhaps for other blog posts.

When should code be reviewed? Hopefully also great question, and the topic of this blog post.

Context

When making a recommendation, I’m trying to get in the habit of always mentioning the context, the situation in my work from which my recommendation arises. This is in response to seeing frustration when people try to follow advice, not realizing that their situation is completely unlike that of the writer.

Here ate Oasis Digital our context is mostly complex line-of-business applications, which are expected to live for a long time and are important to the business operations of the companies that use them. We are almost always replacing an existing system (which a company relies on) or expanding an existing system (which a company relies on).

Another critical part of our context: we have flexible and fast source control, and a group of developers who have learned how to use it competently. We have decoupled source control from build automation, so that we can perform builds of branches in progress without merging them to a mainline. We can achieve a sufficient degree of continuous integration without actually putting each change directly into the same code line.

Review Code Early

How long after code has been written should it be reviewed? Hours or days, not weeks. For this reason, we commit and push code frequently (to a disposable branch of course) where others can see it for early review. It can be a challenge to get past the ego-driven desire to make code perfect before exposing it to the scrutiny of others, but it is worthwhile. By exposing code to review and comment early in its life, a developer can get useful feedback early in a unit of work.

Review Code Often

Another anti-pattern of code review is to look at a given proposed change only once or twice. That is sensible for a very small change, but for a complex change to a complex system it is best to perform code review repeatedly as work proceeds. For example, consider a feature that takes four weeks to implement. Our typical approach, which I recommend to others (if their context is reasonably similar to ours, see above) is something like this:

Review the code a few days in.
Review the code progress once a week or so.
Review the code when it is nearly ready to be called “done” and to go in the mainline.
If there are fixes needed, review those promptly so as not to cause delay.

Review Code Now

Code waiting for review is a drag on the speed of development; the right time to review code is now. A quick review now is probably more valuable than a deep review deferred.

Review Code as a Gate

In some organizations, code review happens asynchronously and sporadically, after code is already part of a project. This risks software quality collapse. Once code is in the mainline of a product, it is arguably too late to review. If a reviewer finds a problem with code already in a system, there will be pressure to sweep that problem under the rug and move on, or to convince your that is not really a problem, or that quality doesn’t really matter, just this once.

The right answer is simple: use code review as a gate through which code must pass before it can become part of the mainline of the project. Use your source control system, and stack up proposed code changes that are nearly ready to go into the mainline. Then periodically perform your review process (whether it is in person, remote, synchronous, asynchronous, etc.). Once the code passes a final review process, then it goes in the mainline. If there are serious problems, the code sits in a branch, a developer improves it, and it tries again next time.

We have had excellent results with this approach, maintaining software quality for years on end even through ongoing development team turnover.

Crafting a Summer Intern Program

Inspired by Fog Creek’s summer intern program, for the last few years we’ve (occasionally) thought about a summer intern program at Oasis Digital. We’ll going to try it out this summer, with a single intern; a more substantial program is possible in the future.

Serious Work

When some people hear (or say) the word intern, they imagine someone who makes copies and fetches lunch. Perhaps in some work cultures that is helpful, but here we have in mind serious work. Our interns will work on serious work:

Projects that are helpful to our company operations
Exploratory programming, to try out ideas that don’t yet warrant commercial attention
Open Source programming, such as improvements to tools we use
Perhaps even a few bits of our real customer projects

The kinds of work could include…

writing software
testing software
reading and writing about software
marketing work around the software

Twofold Purpose

The purpose and goal of our internships will be:

Educate and enlighten the intern
Hopefully also create something useful to Oasis Digital and its customers

Paid vs Unpaid Internships

Many companies are eager to get free help from interns. But it’s clear from a few minutes research that a for-profit company with an intern working on potentially valuable project, must pay. Therefore, we will only offer paid internships.

Location

The internship work will be conducted at our at Oasis Digital office; interns must live in the St. Louis metro area.

Can I Apply?

Sorry – No. We’ve already selected an intern for our trial-run 2011 program. If we decide to continue and expand it for 2012, it will be announced in the spring (of 2012).

Shared-Risk Pricing for Custom Software Development

In any custom software development project, there are well-known risks:

The scope may be underestimated at the start.
The scope may increase over time (not always a bad thing – often a client discovers that additional functionality would deliver additional business value).
The development firm may be unable to deliver any working solution at all.
The project may take more time than anticipated.
The project may take less time than anticipated.

In a time-and-materials pricing model, the client takes most of the risk, and this is generally accepted because the client will receive most of the benefits of a successful project. Many development firms (including many very good ones) only offer time-and-materials pricing.

They do this because of the problems with the other extreme – fixed-price contracts in which an attempt is made to fully describe the software project in advance, then specify a fixed price to build it. In this model, the development firm takes most of the risk, with some unfortunate side effects:

The development firm is strongly motivated to interpret software requirement as narrowly as possible, rather than in a way which maximizes the business value of the software.
The development firm and its client can end up in an adversarial relationship.
Arriving at a project specification and price can be very expensive and time consuming, so much so that this model is often infeasible.
It can result in an overly conservative approach to software development, estimation, and design. The client might be quoted a price which covers the highest amount of time than anyone can imagine the project taking, when then becomes a self-fulfilling prophecy.

However, a key merit in the development firm taking on some of the risk, is that the development firm is in a position to affect the outcome. This suggests a compromise.

One possible compromise between these two extremes is referred to here as Shared-Risk Pricing. It works like so: a small set of core software requirements is developed for a fixed price, then the remainder of the project is billed on a time-and-materials basis. That core set of requirement is intended to demonstrate that the developers can deliver working software, encompass the efforts needed to set up development environments, ensure familiarity with tools, and show progress on any unusual/key features of the software.

The client accepts some risks:		The development firm accepts others:
Scope creep risk.		Risk that the firm will be unable to deliver a working solution.
Risk that the work will go faster than expected getting basic features working.		Risk that the firm will spend more time than expected getting basic features working.
Some of the risk of the project taking longer then expected.		Some of the risk of the project taking longer then expected.

As we start out, Oasis Digital will perform most work on an hourly / T&M basis, while looking for projects where the shared-risk model fit.