Yes, you can forecast software delivery dates with agile

Agile is often mis-used by product development teams to mean, “what ever we end up delivering”. That just isn’t right. It gives Agile a bad name. It’s incorrect and mis-applied by those that don’t understand what Agile is.

At VitalSource, we use Scrum as a way to apply Agile principles to the way we develop, deliver and maintain software product. Scrum gives discipline to the way we do Agile. The artifacts and ceremony around Scrum are important and keep us moving forward. Daily stand-ups, sprint demos, story grooming sessions, retrospectives gives us a cadence that insures we are doing the right thing, delivering value, removing impediments, and communicating with stakeholders and with each other.

Can we make commitments to delivery dates with Scrum? The answer is absolutely yes. We do it successfully all the time. But, before I jump into that, let me first say that because software has no constraints set by the physical world, estimating software complexity is a notoriously difficult thing to do, and you have to understand complexity before you can have accurate estimating. By complexity I mean - how much work will it take to build a software product, which implies, how hard will it be to do? There was a time when there was a lot of work put into figuring out software complexity, but by and large, in commercial software development no one does anymore, but rather the focus has been on better techniques to deliver software product.

To be clear, waterfall models were (and still are) terrible at software completion estimates. Large specs were written, which inevitably couldn’t cover all nuances and use-cases, the specs were handed over to user interface designers, who would design interfaces no one could implement, which was then turned over to developers, who would scramble to write code that matches the specs and user designs, and the dates would slip because the developers had to go back to the spec writers for clarity, and the spec writers would have to re-write the spec, and maybe consult with an end-user, while at the same time the business owners would be harping about the delivery date that could not be missed, developers would have to squeeze in more time, rush to the end, hand it over to QA, who would rush through testing (because you were already late), and developers and testers would fight over bugs, and then everything would be turned over for acceptance testing, which you never really had to time to do, and finally you get the product out the door, most often late, buggy and incomplete, only to find that the delivered product did not end up looking like the spec which was written months before. It was a nightmare, which pitted people against each other.

Scrum takes a radically different approach to software development by putting product managers, QA engineers, and software developers on the same team, working together on a sprint-by-sprint bases to incrementally deliver business value in the product that can be seen and used. Each increment, or sprint, gets you closer to the end game - the product delivery date. The beauty of the model is that after each sprint, the team reassess what is left to do, measures risk, re-prioritizes work, and moves on to the next sprint. Users stories, which represent business value, get completed each sprint and so the product gets incrementally done - and that includes closing bugs so they don’t accumulate until the very end. During the sprint demo everyone gets to see the product evolving. Every sprint represents an opportunity for the team to do a course correction on the path to successful product delivery.

At VitalSource, we deliberately use the term “forecast” when talking about delivery milestones. Because that is what it is, a forecast. The farther out in time it is, the less trustworthy a forecast is, the closer, the more accurate it is. A team can forecast that, “we believe it will take us ten 2-week sprints to have that feature complete”. They base that on their understanding of the their cadence and the complexity of the features (user stories). We have found that our forecasts have been pretty accurate, and have several successes that demonstrate so. We will naturally have time where forecasts will be off, but the beauty of Scrum is that we find out sooner rather than later, because after each sprint we can see if we believe we are on target.

Can we commit to “firm” dates? Yes, we can, and we often do. This is particularly true when we have commitments with external customers or partners. This is essentially “time boxing” the work. In order for a time-boxed effort to work, the team has to develop a prioritized list of work and agree on the minimal needed, and agree that the minimum can comfortably fit into that time-box. If there is time left, they can work down the prioritized backlog of features. Again, we have had success doing this, and I have seen it work may times in my career.

One of the best feelings in the world is to get product out the door. Even better: an awesome product that our customers are excited about and solve their real problems.

Making Product and Engineering work

One of the tenants of the Agile Manifesto is that we value “Individuals and interactions over processes and tools”.   That doesn’t mean we don’t value process and tools, but rather that teams of highly motivated people, working together, and empowered to make decisions in order to get product out the door, can do amazing things.  I have seen it many times in my career.  We get better product, better people, better teams and better retention.

Almost paradoxically, I also really believe Kristof Kloeckner’s insight that:

“Agile without discipline won't scale. Discipline without Agile can't compete.”

Too many software product teams define agile as “whatever we end up delivering”.  That’s doesn’t work and that’s where the discipline part helps.   That’s also why I like Scrum.  Done properly, Scrum adds enough discipline to make agile work.  Sprints, backlog grooming, daily stand-ups, sprint demos, all add structure to the way we do agile.

It’s been my experience, both here at Vital Source and in my previous companies, that the roles of Product Manager and Engineering team in Scrum can have conflict, unless we have some understanding upfront of who owns what.  The way we have chosen to explain ownership is by what questions each role answers:

Product Manager answers: “why” and “what”
Engineer Team answers:  “how” and “when”

Even though we choose to define roles this way, hopefully this doesn’t mean that we don’t listen and get feedback and input when answering these questions.   Here at Vital Source we have Product Managers who have a good understanding of technology, and Engineers who have a good understanding of the Products we deliver, which facilitates discussion and consensus.

To clarify the roles some more, the Product Manager owns the priority of the backlog, and the message of why things are in the backlog and why they are in that order.  PMs spend time talking to sales, account managers, stake holders and customers in order to prune and manage the backlog.  PMs spend a lot time in both outward and inward communications about the products they manage.

The engineering team is responsible for the execution of the backlog.  By using estimating techniques, the engineering teams estimates how many sprints something will take and when coding and testing will be done in order to deliver a solid product.  When considering implementation, the engineering team will make time for technical debt, and make decisions on tools, languages and software architectures.

If would not be appropriate for the engineering team to change the backlog order without sign off from the product manager, neither would it be appropriate for the product manger to commit to a delivery date or technology implementations with out sign off from the engineering team.  When I personally see these things happen, I speak up.  Hopefully others do as well.

That’s not to say we won’t make mistakes along the way.  We are all at different stages of learning the process and coming up to speed on what we do.  I hope we can be tolerant of mistakes and helpful when things go wrong.

If we can truly learn to value "Individuals and Interactions" and worked towards being a jelled team, we can deliver great product and have fun in the process.

Technology teams should own customer-facing products, not technology

In a business that is responsible for delivering a technology product, I think something incredible wrong happens when a group of engineers feel they are responsible for delivering technology and not for delivering a product that gets delivered to market.  The engineering team starts to focus on the wrong thing - building more technology instead of building business value.

This is a core value that drives the decisions I make and the way I approach technology leadership, and drives the product delivery model I implement.  This is one of the reasons I like Scrum teams - properly done, they encourage this style of ownership.

Engineering teams should be aligned with business units that deliver customer value.  They should be strong participants in and contributors of the culture.  They should understand the business.  They should know and interact with the business teams, they should have a tight relationship with the product managers.  You will get better product, you get happier engineering teams, more retention.

I love it when technology teams feel like the "own" a product and are passionate about it, rather than being soulless cogs in a machine processing tasks assigned to them.   As a big added bonus, if you have ownership, process becomes a lot easier.

If you want better technology product, make your engineering teams responsible for the product they deliver, not for the technology they build.  You will get better product AND better technology,

Shine a light on software errors to increase quality

My team develops, tests and operates a fairly complex SaaS product.  We have customers who run their business on our product.  They pay us money and they expect it to work.

I am proud of my team - they deliver a high quality product.  We have a release every 10 weeks with minor point releases in between.  For a complex SaaS, we do a lot of releases.

I believe that the quality of the product you deliver goes up by not hiding errors.  In our application, every time user action generates an error, whether it is visible to the user or not, our application generates an email that goes to the DevOps team and myself.  Every time.  Very few of the errors block or affect user activity and almost all are recoverable, but we know they happening and then we look for patterns, we investigate and we prioritize fixing them.  If we believe a user is blocked or having trouble we reach out them and ask if we can help.

I am a big believer in exposing errors and bugs in a software application.  If your code is silently logging to some log file then you never know they are there, you may ignore them as "expected" and no one ever gets around to fixing them.

Here is a cool side affect of exposing errors - everyone becomes more focused and aware of them.  The QA team makes sure that we test thoroughly and known errors are captured.  The software developers want to make sure their code works - the quality of the entire applications goes up.

If you want to quality of your product to go up, put in mechanisms that expose errors that users are seeing to your technology team and make it clear that minimizing them is a high priority.

Jelled Software Teams

A truly jelled software development team is a beautiful thing to see in action. They talk to each other, not around each other.  They hold each other accountable.  They push towards a goal together.  They deliver very cool product that they are passionate about getting right.  They take pride in their work. They occasionally goof-off together. They have one goal, and they all know what that goal is.

If the team is functioning right, they care more about getting the product right for the customer than what an internal stake holder (like the CTO) thinks. They are willing to fight and standup for what they believe the right thing is to do. Like I said, it really is cool to watch these people in action.

But, here is the thing: not everyone recognizes that software development is a team sport, and as a result teams are often mismanaged.  Computer Science and Engineering degrees teach the discipline as a solo effort.  In college, you work on projects by yourself and rarely collaborate - and then when you get into private industry, you are thrown into a team to work on a product. Stake holders and senior management in many companies come from sales backgrounds, where they rise through the ranks competing against other people in their own teams, and generally struggle with what it means to build a well-functioning team.  People with accounting and liberal arts backgrounds might not get it get it either. Heck, a lot of technology leadership struggles with this too.

I could write a book on what it takes to build great software development teams (and some day I might), but if I could give someone some quick advise there two things: form small teams and lose the command-and-control leadership style.

Any software team with more than 3-5 people on it makes it difficult to jell. Meetings take forever, you loose track on who is working on what, and use loose some of the closeness that comes from working with a small group of people.  This small team is not a "chief surgeon model", where one person is the principle and everyone else is there to help him or her.  This is a team of peers where everyone has an equal voice at the table.

The right sized team is about 5 people and consists of 2-3 developers, 1 QA person and a product person.  A technology group may consist of many of these kind of small teams all working on different tracks during a release cycle to get something out the door.

To have strong jelled teams, you really have allow them function as peers to technology leadership.  In the 21st century, especially when dealing with knowledge workers like technology people, it isn't unusual for an someone to know more than their boss about something.  And, that is OK.  It shouldn't come as a challenge to authority, but should be encouraged. Mistakes will happen, but a good team will recover quickly and learn from them.

Some great benefits from jelled teams: they are happier, enjoy working together and deliver better product. Turn over and discontent also go down. People stop complaining to their manager and start talking to each other to solve problems.

It is worth the effort focus on teams.  Like I mentioned in a previous post, most teams have people problems not technology problems, and having jelled teams goes a long way to solving them.

Yes, Software Architecture really does matter

Software Architecture really does matter and, apparently, this is not a commonly held belief.

All too often, software developers are hired to "program" an app and get it out the door.  Bad patterns from previous gigs are carried over and perpetuated. Whatever technology leadership is in place just reacts to business pressures, and puts pressure on the team to deliver while trusting the developers to get the architecture right.

At some point architecture decay sets in, the code gets brittle, new features take forever to add, new hires can't really figure out the code,  the software gets bloated and runs slow, management gets frustrated and demands to know who is responsible, someone gets fired or quits, and new leadership is brought into "fix" the problem.  I've observed this pattern several times.

Here are my general guidelines for software architecture:

Don't be special!

Software architectures get into trouble when a couple of developers think they have a special set of problems and decide to be special in the way they apply well known patterns or technologies.  I've seen this many times, and have had to pay the price to fix it.  There is a reason why patterns develop over time, and why the community of developers apply something in a particular way.  Use the technology the way it was intended to be used. Otherwise, the next group of people won't understand your "special" techniques and you won't be able to upgrade or evolve properly and then someone will have to undo what you did. Don't be special.

Listen, pause, think, code, repeat.

Before you write the fist line of code, pause and think.  A one hour or one-half day discussion about where everything fits and what the proper architecture should be pays very large dividends.  Find an architect or senior developer, sit with them and bounce around ideas.  Look at what others have done.  Read articles, blog entries or books.  Avoid inventing something new, use something that already works.

Don't go dark

One of the worst things you can do when coding is go dark to the rest of your team.  You need to share and they need to know what you are doing (daily stand ups really help here).  Review your architecture and code with your team often.  Tell them what you are doing often. Keep running your ideas past them.  Doing all of this will minimize the chance that you will do something dumb.

Technology leadership should really lead

Software architecture should be a top-level item for technology leads and managers.  Talk about it, espouse it and be familiar with the architecture that the coders are developing.  Too often, technology leadership has no idea about the software architecture.  Some managers manage by Gantt charts and feature lists -  that's not leadership, that project management.  Lead and get in front of architecture issues. Make sure senior management is aware that this is important.  Add time to the project for it.  Schedule meetings to discuss it.  Give senior and lead developers time to address it.  

Seriously, architecture is important stuff.  Don't just hope it happens right.

If nothing else, be authentic

This last week I attended the re:invent Amazon Web Service Conference in Vegas.  It was a good conference, in a good venue.  I learned a lot of good technology stuff.  One non-technical session I really enjoyed, was a key note address in the style of a fireside chat, with Jeff Bezos (you can see it here).

Bezos is an intense, really smart guy.  What he has done at Amazon is incredible (interesting side note: he does not have a degree in business, but a degree Electrical Engineering and Computer Science).  What struck me most about his talk was his authenticity.  He would admit he didn't know sometimes, and talk about mistakes he has made.  He talked about working customer service calls and sweeping the warehouse floors at Amazon. Not a lot of pretension there.

Authenticity is key in a leadership role.  Engineers are especially really good at picking up phoniness, and once they sense you are phony, they loose respect for you; and without their respect, you can't lead.   Besides, it's requires too much negative energy to keep pretending to be something you are not.  If you don't know, say you don't.  If you have doubts, say you have doubts - even if it is in yourself.  If someone else knows better, ask their opinion.

Authenticity requires a fair amount of self-awareness, which few people are really willing to spend time on.  You have to know who you are, what you know and what you don't, and, most importantly, be willing to put your ego aside and not be the smartest guy in the room.

Authenticity also means that you recognize that people "under" you are just like you.  You are no better than them, and that you are all working for a common purpose.  You also need to be able to recognize that in many (if not most cases),  those working for you contribute more than you to the success of what you are working on.

I love this quote from Jack Welch, from his book Winning (hat tip to TechCrunch):

"When I was at GE, we would occasionally encounter a very successful executive who just could not be promoted to the next level. In the early days, we would struggle with our reasoning. The person demonstrated the right values and made the numbers, but usually his people did not connect with him. What was wrong? Finally, we figured out that these people always had a certain phoniness about them. They pretended to be something they were not ­­­— more in control, more upbeat, more savvy than they really were. They didn’t sweat. They didn’t cry. They squirmed in their own skin, playing a role of their own inventing. A leader in times of crisis can’t have an iota of fakeness in him. He has to know himself­­ ­— and like himself ­­­— so that he can be straight with the world, energize followers, and lead with the authority born of authenticity."

If you want to have success and really lead,  lay aside the ego and start to be authentic.  As counterintuitive as it may sound, those that work for you will have more respect for you, approach you more, and enjoy working with you more.  Oh yeah - and your team will have more success.

Why are software delivery estimates so hard to get right?

A day after Mountain Lion came out for the Mac, I upgraded.  It works great and I am very happy with it.  If you noticed, Apple didn't let anyone know the exact release date,  until the day before it was released. We still don't know when iOS 6 will be released by Apple - only that it is coming out sometime in the fall.  This is now the norm with software vendors.

When I was getting my graduate degree in CS, I spent a lot of time thinking about software complexity,  which was the subject of my master's thesis and project.  I built a cool software model around AJ Albrecht's work for measuring complexity called Function Points.

Software complexity is important, because understanding complexity helps you understand how long it may take you to build something.  If you know that a software system has say, n complexity, before you start building it and you know how long it takes to build something of n complexity (based on historical data), then you know how long it takes to build that software system.

The fundamental problem is that you never really know upfront how complex a software system is, and hence how long it will take you to build.  This is something that people with production-minded backgrounds have a really difficult time getting their minds around.  It's not like manufacturing printers or building houses - software is not constrained by the laws of physics, has many more moving parts, and can be changed at the very last minute.  As a matter of fact, in a good software development process, you delay as many decisions as possible - because you are always learning things as you are putting product together.  Some people say developing software is more like writing a book or producing a movie, and that sounds about right to me - you can and should change things at last minute, as long as you understand the costs.

Also - the larger the project, the bigger the estimate risk.  I personally like breaking up large projects into smaller deliverables,  which gives you insight on how well the product development is going.  In our current product, I like (and use) two week sprints and 10 week release cycles.  That means that every 10 weeks we deliver new product like clock work.  If something will take more than 10 weeks, we break it up so that deliverables fit into that window.  If a 10 week release cycle deliverable it not useful to the end user, we keep it in-house - but interestingly that is rarely the case. We can usually find value to deliver every 10 weeks.

A time-constrained release cycle also gives you a time box for delivering value.  Many times we will constrain the delivery of a feature to a release cycle.  This forces us to make decisions about what is really import.   There is a lot that can get left behind, but we often find those things were not that important.

It also really helps to have senior software developers with deep experience.  Nonetheless, it's non-trivial to estimate how complex a software system is before you build it, but if you break up your product into small deliverables, and time constrain those deliverables, you have a good chance of hitting delivery estimates.

It's an app!

This week we delivered an app for iOS devices.  It's a mobile portal to our enterprise operations platform, and it actually is pretty cool, robust and functions well.  It connects to our EC2-based infrastructure over a secure connection.  You wouldn't use it unless you were a customer.

Our app is non-trivial - it interacts with our cloud-based systems to do schedule calculations and manage complex tasks.  It took us a while to develop and I think we got the first pass right.   Like any other piece of software,  there is things we can improve on, bugs we will find, and work flow improvement we will make over the next few release cycles,  but I am proud of what our team has accomplished.

This is not my first iOS app, but I learned somethings again in the process.

First - having a good iOS developer in-house to prime the pump is crucial.  Once the pump is primed, good software developers with deep experience can jump in, pick it up, and contribute.  We did the real thing - Objective C using Xcode.  I have not been impressed with third party iOS development packages and they lock you in to their framework.

Second - the app store approval process from Apple is still a pain.  They filter out incompetence by the complexity of the process.  Maybe it's on purpose.

Third - Mobile user interfaces are very different from web portals (no surprise).  We didn't look to re-invent the wheel here.  We looked at what others were doing and followed similar UI patterns. No need to complicate things.

The iOS ecosystem is cool.  I don't mind objective C and Xcode - I just wish approval and deployment were easier.

Agile: dropping the Scrum training wheels

Many of us have been using parts of the Agile Manifesto for many years.  What you find in the agile movement,  is a rollup of good practices that many of us long time software development practitioners have found work.  I am a big fan of agile principles, specifically short development iterations, the focus on working code, and the focus on human interactions over documentation.

A couple of years ago we introduced scrum at my current company. Scrum enforces good practices that agile talks about, by introducing daily stand ups, sprints, demos, etc... It also introduces a Scrum Master - a facilitator that enables communications and makes sure that decisions are made.  A good Scrum Master also keeps the process wheels well lubricated to make sure everything moves along well.

We went all "in" on scrum - Story boards, story pointing, estimates - everything pretty much by the book.  We bought Jira + green hopper to help manage everything.  All went pretty well first year.  Every sprint and release cycle we got better at the process. People acted like adults and owned things.  Estimates were made, product managers were brought into the loop.  It also helped tremendously that I hired a Scrum Master who had lots of deep experience in Scrum, and who is a fantastic communicator and facilitator.

Then, we started dropping parts of scrum. Scrum helped us stick to agile principles, but over time, we started dropping some scrum things that we grew out of.  Scrum purists would scream foul, but I have always believed that process should adapt to your people and circumstances, not the other way around.  I believe we do agile, but not scrum anymore.

Here is some things we dropped:

• A full time Scrum Master.  Our Scrum Master is now our director of Software Development.  He still helps make sure that the process works well, but by and large the role of scrum master has been taken over by the software development teams themselves.  We have four development teams of about two developers and one test engineer.  They know enough about the process to move things along themselves.  If they need help, they ask and we get it for them.
• Story Point estimating. Story point estimating blows.  It's hard to get estimates right. You have to keep a history, but when people move around teams, the estimates get all messed up.  Now, we still develop stories and talk about them upfront. We still do exit criteria on stories, we prioritize stories, but we just don't story point them.  How do we estimate how much can get done in a release cycle or sprint? We do rough estimates with everyone involved ("I think we will get this far").  You know what? those work as well as all the time we put in story pointing.  Sometimes we are off, more often then not we pretty much on.
• Sprint retrospectives.  We do retrospectives, but not that often. If the teams are always talking (and they should be), there should be no surprises.

We have kept stand ups, demos, sprints (two-weeks) and we like Jira.  The key is that we are free to evolve the process as we need to, and don't necessarily feel we need to be held up by the scrum model.

There are plenty of things I wish we could do better.  We struggle communicating business workflows well, some developers try to be too heroic and do too much,  and have a tendency to leave the test team behind.  But, here is the key: we talk about these things and we try to do better every sprint.  

I know this is heretical to many of my scrum-devoted friends, but I say: make the process work for you and drop the scrum training wheels if you feel you need to.

Software Development: You don't have a technology problem, you have a people problem

"There is nothing new under the sun"  - Ecclesiastes 1:9

We rarely invent anything new in commercial software development.  Most of what we do is to apply well known patterns and technologies to the domain we are working in.  Now, this does not mean what we do is trivial or easy, but generally, we are not inventing anything new.

So then, why are so many software projects, late, bloated, over budget or failures?  According to Tom Demarco, in his classic book, Peopleware, it's not because of technology issues, its because of people issues.

That's right, you don't have a technology problem, you have a people problem.

Bad communication, egos, ignorance, office politics, inexperience, weird personalities all are bigger problems than technology issues. These things all get in the way of success. Unfortunately, the vast majority of technology leadership struggles with dealing with people issues.

It's easier to deal with a build problem, or to fix a bug,  then it is to figure out why Sally and Mike are not getting along on their project. Technology problems are discrete and deterministic, people are messy and emotional.

I have found that finding leadership that is both technical and people-oriented is very hard, and when you have someone who has both, hold on to them, but have to build these soft skills in your existing staff.  I do this following some loose principles:

1. Technology leadership needs to be technical.  This is critical - you can't lead people unless you know what they do so that  you can participate, lead and provide input.  You have to know how to code.
2. Focus on "doing the right thing", not pleasing some internal stake holder.  When you focus on doing the right thing, politics and bickering takes a back seat.
3. Don't worry about who get the credit.  This is easy to say, hard to do, but when you have a team that really believes this, great things can happen.
4. Remember that software development is a team sport.  Empower the team to make decisions and allow them to be responsible for their actions.  Treat them like adults.
5. Take time to talk and listen.  Spending an hour listening to a person who is struggling with a decision, giving input (not telling them what to do), and helping them make a decision is a critical management responsibility.  I make sure I have time every day to talk to people and listen.
6. Treat people like adults, not like children.  Management is not like parenting.  The people that work for you are adults, treat them as such and respect what they do.

It is true, there is a lot malpractice in this industry related to technology, but the issues all start with people.  People design, implement and test software.  Focus on your people problems first and your technology problems second, and you will have a lot more success.

On "Working 40 hours, and mailing it in"

A good friend of mine, who I have a lot of respect for, asked me a rhetorical question on Friday that has bothered me all weekend.  Referring to someone we both know, he asked "What's wrong with working 40 hours a week and just mailing it in?"  The funny thing is that my friend is one of the most passionate and involved guys in technology and technology processes I know.  A family man, who balances his work and life well, nevertheless he does not "just mail it in" when it comes to his career.

Once in my career a few years ago, I was in a "just mail it in" position.  I had a hard time filling 40 hours a week.  I was not challenged.  I was bored. Oh, I had a nice office, was well treated and respected, but not being challenged led me to spend a time finding more interesting things to do - and initiate quiet a few office pranks.  I left for something more challenging, that certainly required more hours - but, and here is the important point: it was a lot more fun!


As a technologist and software developer I have always looked for people in my organization who have a passion and are deeply interested in what they do.  People who write code on the side for fun, are the kind of people I want to work with.  Don't get me wrong, I am a deeply committed family man and have tried hard to spend all the time I could with my children when they were small, and now have a very good relationship with them now that they are college age.  I love spending time with my wife too.  But, my family knows how enthusiastic and interested I am in technology.  I love to build it and use.  I can't imagine having a job and career that I just clocked in for.  That would really blow.

Henry B. Eyring, the son of famed theoretical chemist Henry Eyring tells a story which I can relate to:

'Henry Eyring encouraged his sons to study physics and to prepare for a career in the sciences. Hal dutifully majored in physics at the University of Utah, but one day when he asked his father for help with a complex mathematical problem, it became apparent to Henry that Hal did not share his passion.

“My father was at a blackboard we kept in the basement,” Henry B. Eyring recalls. “Suddenly he stopped. ‘Hal,’ he said, ‘we were working at this same kind of problem a week ago. You don’t seem to understand it any better now than you did then. Haven’t you been working on it?’ ”

Hal said he had not. He then admitted to his father that physics was not something he constantly thought about. His father paused a moment and then, in tender words that released his son to pursue his own professional passion, he said, “You ought to find something that you love so much that when you don’t have to think about anything, that’s what you think about" '  (source)

That is great career advice I share often.  Technology for me is something I think about when I don't have anything else to think about.  It's cool and fun, and that's why I don't just work 40 hours a week and "mail it in".