David Scott Bernstein's Blog, page 12

Answer Questions Quickly

One of the most important skills
for a Product Owner is to answer questions quickly, which means that they have
to really know their product and understand WHY it’s needed, WHAT’s needed, and
WHO it’s for.

Developers have to dive deep when
they’re writing software and they come up with questions that non-developers may
never have anticipated. Understanding these questions and finding the answers
that best fit them is critical to building a really good product. This comes
from knowing what we want to build and also knowing some of the challenges that
the people face when building it.

I act as the Product Owner in my
lab course on Extreme Programming practices and I understand the kind of
questions that developers have when they’re building a software product.
Developers really appreciate getting clear answers to their questions so that
they can move forward quickly.

The number one blocker to all
software development is technical debt. It seems like we’re always fighting
with existing code whenever we want to enhance a system. But the number two
blocker in software development is developers not getting questions answered
quickly. Because of this we make assumptions and unfortunately our track record
reveals that we don’t always get it right and so we have to undo new things
that were based on assumptions that didn’t turn out to be true.

How frequently does this occur? How
often do developers end up reworking decisions they made previously? According
to an NIST study, on average 80% of a software developer’s effort is spent
reversing irreversible decisions made in the first 20% of their effort.

Shocking but true! When I see
figures like this I realized that we don’t place enough value on sequence and
understanding how to effectively build a good software development process.

We figured this out with building
construction. The building industry isn’t suffering the major catastrophes that
we in the software industry are facing. Sure, there was a time when buildings
were unreliable and collapsed spontaneously. We know this from looking at
archaeological digs. Even the Cathedral of Notre Dame had to be rebuilt three
times before they invented the flying buttress which still stands today. Progress
is being made but it’s slow and the software industry is a young industry.

In a lot of young industries there
is usually a key player that leads the effort. Consider the film industry which
is also a fairly young industry. There’s a collection of  a few film directors that are trusted by
Hollywood with hundreds of millions of dollars for their budgets to make a
feature film. It turns out that it takes great skill to make a feature film and
this not just the director but it’s a collaborative effort. It takes a lot of
great skill to write a great screenplay and do all of the roles both behind the
scenes and in front of the camera but to put a great film together really
requires the vision of one individual who is usually the director.

In the same way, the software
development industry has a pool of superstars and fairly often on teams they are
not actually the developers but the Product Owners who hold the vision of the product,
so the product really gets made to be a useful and complete tool.

Great products are the result of a
team effort and great teams are often led by great Product Owners. Great Product
Owners clearly communicate the vision of a product and are able to answer
questions quickly so that the development team can get to the business of
building it and delivering it to customers rapidly.

Note: This blog post is based on a
section in my book, Beyond Legacy Code: Nine Practices to Extend the
Life (and Value) of Your Software called Seven Strategies for Product
Owners.

Describe What You Want Not How to Get It

So much of good software design
comes down to separating the WHAT from the HOW.

WHAT we want should be expressed in
the interfaces of the services that we create. It should clearly state WHAT the
service provides, the parameters that it needs to take in, and the value that
it returns. Our services should provide strong contracts that guarantee a range
of specified behaviors.

Think about the result that the
client wants. Think about being your own customer. This is how we want to think
when we design APIs. We want to take our callers perspective because this is
how we designed well-encapsulated systems that are straightforward to interact
with.

One of my working definitions of
the key code quality called encapsulation is about hiding HOW we do something
by only saying WHAT we do. This is a form of hiding implementation details and
we want to do this in the software that we create because when we do, it
lessens the impact of change when it happens in our code.

Most software is written in such a
way today that it is intertwined with itself and this makes it very difficult
to extend software and add new features. According to several studies that I
reference in my book, Beyond Legacy Code, it cost twice
as much to make minor enhancements to existing software than it took to create
that software in the first place.

When I see statistics like that I
realize that we have to build software differently as an industry. It’s not
like we don’t know what to do. We’re not like doctors were in the Middle Ages,
without germ theory or a good understanding of biology to draw upon.

We have the practices of Extreme Programming and good design principles and practices that are known throughout our industry. But the knowledge of good programming practices throughout our industry is quite uneven. One of the main reasons for this is that our industry is growing so rapidly. Software developers are some of the most in-demand professionals today and the supply of available developers can’t keep up.

Uncle Bob Martin says that the base
of professional software developers doubles every five years and has done so
for decades. If he’s right, then it means that more than half of the people on
every team have less than five years of experience. Couple this with the
barrage of frameworks and languages and tools and methodologies that people are
confronted with daily and we begin to see why there is a big gap in
understanding of exactly what software development is or should be as a
profession.

But regardless of the standards and
practices that we use to actually build our implementations, one of the most
valuable practices that I have found as a developer is to find ways of hiding
the details of how I implement a feature from my callers. That way my caller won’t
depend on those details so I’m free in the future to change them without affecting
my callers.

That’s the real payoff of being
implementation independent. When we can hide implementation details it means
that we can change them later without affecting other code. However,
encapsulating implementation details is a subtle business. We have to be
careful about the assumptions that we make.

I remember I was working with a
team of developers and teaching them one of my very favorite techniques for giving
code greater extensibility by providing a class with a static method to new itself up. I called this method getInstance().
A lead developer saw calls to getInstance() in my code and asked me why I was
using so many Singletons.

“Why do you think I am using Singletons?”
I asked.

He pointed to the getInstance() method calls in my code and said that they were creating Singletons. But my getInstance() method wasn’t doing that, it was just newing up an instance of itself.

Why did he think that it was creating a Singleton? Because the Gang of Four used that method name in their book, Design Patterns: Elements of Reusable Object-Oriented Software, when explain the Singleton design pattern. Is this a valid reason for me to treat that name as always invoking a Singleton?

From the client’s perspective it
simply wants to get an instance of an object and it should not have to care
whether it’s being given a Singleton or not. What happens when we realize that
just one single instance isn’t enough to service all of our callers, so we
refactor to a Doubleton or Tripleton or an object pool. When I do this do I
tell my clients they have to change the name of the getInstance() method
because it is no longer invoking a Singleton?

Clearly, this is a slippery slope.
It’s not the clients concern how I manage the instance internally. The client
simply wants to get an instance of an object and leaves it up to the object to
decide how it should fulfill that requirement in the best way possible.

This is what we mean by a separation of concerns. Client’s don’t need to be concerned with the details of their caller’s work. I also refer to this as assertive code where objects are responsible for themselves and the state they manage. Giving objects the ability to be responsible for themselves, including instantiation, lets them be more autonomous so we build software that’s more functionally independent and straightforward to reason about.

Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Product Owners.

Help Developers Understand Why and for Whom

The traditional ways that we describe how to build something, whether it’s a blueprint for an office building or the specification for a computer program, it always involves a document that describes WHAT to build and often includes information on HOW to build it.

However, these documents are often
missing critical information on WHY these features are wanted in the first
place and WHO they are for.  Both of
these pieces of information tell us a lot about what to build and knowing them
we can often build better features for our users then was originally conceived.

This is the whole point of Agile and of getting feedback. We want to get feedback on many levels. We want to know from users how we can make their lives easier. We want to know from stakeholders if our software is meeting their needs. We want to find ways of excelling and delivering more than what was asked for.

This is a bit of a different approach than the hard-core negotiating business contract deals that are sometimes made. But I’m seeing more and more software written under contract using Agile methodologies. Clients are recognizing that a block of time from a highly productive team will always yield valuable results.

When we understand WHY a feature is
wanted we can often build a better feature than was originally specified. This
is the whole point of feedback in Agile, but we have to connect our feedback to
the people who can do something about it, the developers on the team.

I always encourage development
teams to connect with their users, whether it is at a conference or a tradeshow,
or driving down to visit users in their offices because I know what a profound
effect it has on both the users and the developers. Users feel really
appreciated and they begin to really open up and give us valuable information
on how to improve our products. For developers, I see their eyes open up in
many ways for the first time as they begin to really see how people assimilate
the code that they wrote and use it in the work or in their lives.

Who we’re writing code for also should
have a big impact on what we built. We want to visualize being the user or the
client of the services that we’re providing so that we can make it
straightforward to use our services. This concept was echoed by the Advice from
the Gang of Four when they said, “Design to interfaces.”

As we move from thinking about what
to build to why we’re building it in the first place, we get to challenge some
fundamental assumptions that we may be making. We may also get to validate that
what we’re building will really satisfy our customers before investing in
actually building it. This helps us spend our client’s resources most
effectively. We end up building a system that satisfies more of the customer’s
needs by understanding what those needs are up front and ideally embodying them
in a set of acceptance criteria that we can automate through acceptance tests.

When we understand why features are
wanted and who they are for, then we have the information we need to build
better features that addresses the needs of our users more fully.

Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Product Owners.

Use Development for Discovery

Before you begin to build a house
and break ground on the foundation you better have a blueprint and know exactly
what you’re going to build. In physical construction, we really need to plan
things out ahead of time to ensure that we have the right materials at hand and
that things come together as we want them to.

This is a fundamental constraint of
physical construction and it forces us to think about and construct physical
things in certain ways. Virtual things do not have the same limitations and so
in many cases we can find more effective and efficient ways of constructing
virtual things then if we were to just follow a similar plan that we would for
constructing a physical thing.

Virtual things don’t have the same
limitations as physical things and Agile attempts to leverage this fact when we
construct software. Instead of designing a system up front, we can design it as
we go and if we do this correctly, it can be more straightforward and yield a
far better product that if we were to plan it out all upfront.

I did not believe this at first and
so I was reluctant to try Agile in the early 2000’s as a successful Waterfall
developer. How can I start coding when I don’t know what it is that I’m coding?
That’s what I thought but at the time I didn’t realize that I actually knew a
lot about what I needed to build, I just didn’t know everything, and I didn’t
need to.

In my experience, we rarely know
everything about a project before we start and operating under the false
assumption that we think we know everything can cause problems. Also trying to
figure everything out upfront in the planning stage is like trying to visualize
the future. There are so many variables and we as visualizers are so imperfect,
we often wind up getting the wrong impressions and missing key concepts that we
don’t recognize until were in the midst of it and it costs a fortune to change.

Writing software is the process of
working through problems and so when we get requirements that ask us to address
these problems and ask us to estimate how long it will take to resolve these
problems, we are at a significant disadvantage. It’s like asking a scientist to
give them the results of an experiment that they haven’t yet designed.

Managers are constantly asking
developers how long it will take them to accomplish a task and the truth is that
most of the time developers really don’t know. Developers are asked for
estimates and when they give a date their estimate there taken as commitments.
The word “estimate” and the word “commitment” are different, and they imply
different things but I find almost universally that a programmers estimate is
immediately turned into a commitment to finish a piece of work on a certain
date, whether they’re aware of it or not.

In my experience, software
developers are very well intended and many times optimistic about how much they
can get done in a short period of time. They shouldn’t be faulted or penalized
for their optimism.

I think the whole estimation
process is often a waste of valuable time and resources. I’m a big proponent of
the #NoEstimates movement. No estimates doesn’t mean never, ever do estimation
but rather do it appropriately, as needed, but also recognize much of the work
that one has to do to build a component is involved in doing the estimation
except at the end of the process you get a number instead of a working feature,
which is not nearly as valuable.

If you were really hungry and went
to a restaurant to ordered dinner and the waiter gave you a number instead of
your meal then you’d probably be very upset but somehow in the software
industry is okay for us to expend enormous amounts of time and effort to
deliver just a single number, which is often wrong anyway.

A single number is fallacious
because estimation is a probability and probabilities are not expressed as a
number but as a range of numbers. Rarely do I see managers ask for a range of
numbers when doing estimation, but having a range of probabilities can inspire
the right kinds of conversations about the work to be done, such as adding an additional
feature that pushes out a delivery date by X number of days and reduces the
probability that this release will be ready at a specific date by a specific
amount. Now we can engage in a conversation about if it’s worth it or what’s
our backup plan is or any number of productive things.

When managers ask developers how
long it will take to finish a feature they are giving their power away, they’re
playing victim. Developers don’t want this responsibility. Instead, what if management
said, “Look, we have this much money, which means that we can have you work for
this amount of time with this size of a team. Build as much as you can of the
most important features within those limitations.”

If you trust that the team is doing
the best that they can and that you have a good software development process, then
you will always get the best results that you could with the resources that you
have, so what need is there for estimates? It’ll get done when it gets done.
Estimates don’t change that, and they just take time to generate so they’re not
always worth it.

Of course, there’re planning and
release cycles and other issues that do need delivery dates but remember, in these
scenario management is coming to the developers and saying that want to release
on a specific date and asking how much they can deliver by then. Taking this
approach can often lead to a better product and a more effective software development
process.

Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Product Owners.

Be the SME

I’m kicking off a new series of blog posts based on the Seven Strategies sections in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. The next seven blog posts will each be based on a different strategy from the section in my book called on Seven Strategies for Product Owners. You can also see the original blog post here: https://tobeagile.com/2013/07/16/seve.... 

SME stands for subject matter expert, the people who understand the domain that we’re building software within. These people have specialized knowledge and we want to find ways to incorporate that knowledge into the software we’re building.

Understanding a domain is often the first step in being able to build something useful for it. This is really what the analysis phase is all about. We do analysis to get familiar with the domain, understand the terminology and be able to represent the domain accurately in our object model.

Subject matter experts are usually not software developers but I still want a subject matter expert to get a good sense of what my code does just by reading it because I express my code in the domain model as much as possible using names that represent the concepts within the domain so even though a subject matter experts may not understand a computer language they should be able to glean the key things that my code is doing just by looking at it.

The most evolved people are self-directed, and I find that the most advanced software development teams are also self-directed. Developers are not necessarily subject matter experts in the area that they’re building software in but given time we almost always rise to the occasion and become domain experts after writing code in that domain for a while. When you work in a domain for years you get quite familiar with it. I know teams that understand the products so well that they take on the role of product owner themselves. This is not something for beginning teams or even many long-standing teams, but sometimes a team will just click, and they become the best representatives of their users.

This doesn’t always happen with teams but when it does it can be ideal because then the customer is fully represented by the development team. This also tightens the loop between what we build and the impact it has. Seeing how our code impacts other people can be empowering and when developers get a taste of how the work that they do can positively affect other people’s lives, then they can get very excited and often become much more engaged.

As developers, we can’t help learning about the domain that we work in. I worked in a huge range of domains as a software developer over the last three decades. I know about such diverse things is image processing and video compression, boat auto-piloting, wholesale bank accounting, and dozens upon dozens of other domains. 

One of the things I love about being a software developer is that I get to constantly learn about new things and new approaches to problem-solving. Each domain has its own unique perspective and by learning about that domain, I often find that some of the concepts are transferable to new domains that I’m working in.

Being a software developer is like being a model builder. The models that we build are temporal models, they model behavior of a system. The model is only good if it’s accurate and what we model comes from a deep understanding of the subject matter that were working in. The more we understand the domain the more accurately we can model it.

Why Practice 1: Say What, Why, and for Whom Before How

In honor of the 10th anniversary of this blog, which I first started under the name Techniques of Design and then became To Be Agile, I’m starting a new blog series. Actually, I’m starting nine new blog series, a series on each of the nine practices from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. 

Also, I’ve recategorized my blog posts and most of them relate to one of the nine practices. Now you can look for posts based on your specific needs around the nine practices. Over the last decade, I’ve written hundreds of posts on this blog on a variety of agile engineering practices. 

I tried to make the content of my blog accessible to both developers and managers. Both in my blog and in my work I try to make the agile technical practices accessible to everyone so that the entire organization can get on the same page with how we build software.

My book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, focuses on nine specific Agile engineering practices that support the creation of extendable software.

This is the first post in a series of nine blog series, one for each of the nine practices in my book.

This first series is on Practice 1: Say What, Why, and for Whom Before How. While this is not a technical practice per se, I think that it is one of the most important practices for all technical and non-technical people on a development team to do.

Agile does not replace requirements with a single sentence story but rather uses stories as placeholders for conversations between the Product Owner and the team about what to build. One of the traps that I see teams get into is that when they talk about features they speak in implementation details. This is partly because of the way we communicate in English. We speak in terms of implementation and so when a Product Owner or Business Analyst talks about a process or how the system should behave, they often talk in terms of implementation details. 

This is not a good practice. It’s far better to focus on what you want, why you want it, and who it’s for. This helps the team better understand how to create value for the user of their feature.

I’m a huge fan of Simon Sinek’s book, Start with Why. When discovering a system it is often best to start with why the system is wanted in the first place. In my book, I say start with what because Practice 1 is really about communicating ideas and not about generating ideas. I fully agree with Simon Sinek when he talks about starting with why but he’s talking about generating ideas and anchoring them in meaning. In Practice 1, I’m talking about communicating ideas and specifically communicating the features of a system.

I find that when I think about features in terms of who it’s for, why they want it, and specifically what they want, then I can build more of what they value and so the system is more successful for them.

It’s easy to get bogged down in implementation details. I want to try to avoid that by focusing on goals and constraints. What is it that we want to achieve and in what context do we want to achieve it? We can figure out the details later.

In agile software development in general and Scrum software development specifically, the customer representative or Product Owner plays a critical role. In many ways, I feel that the Product Owner acts like the director on a movie set, helping to coordinate a large effort.

Not everyone can direct the feature film. And there are very few directors that studios will give $100 million to in order to make a film. Great Hollywood directors are superstars. On a lot of Agile projects the Product Owner becomes the superstar or the singular visionary for the product. 

The Product Owner isn’t a technical role but it can be a critical role in providing consistency and focus to the product. After all, the most important thing of all is to make sure that we’re building the right thing for the marketplace and that’s the primary job of the Product Owner.

I’m excited that I get to expand on the Seven Strategies that I presented in my book for each practice in these blog posts. The following seven blog posts are based on “Seven Strategies for Product Owners” from my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. Enjoy.

My Ten Favorite iPad Apps

I’ve been so happy this year with my MacBook Pro and my iPhone X that I haven’t really missed having an iPad. But as soon as I got my new iPad last week all that changed and I wondered how I ever lived without it. Here are my top ten favorite apps for the iPad.

10. Netflix

I think Netflix and Amazon Prime Movies are great. I get quality entertainment on demand and with no commercials. Who needs cable or broadcast TV? Netflix and Amazon Prime Movies have awesome interfaces, unlike every major cable channel supplier I’ve tried. Cable is dead. Long live online video!

9. YouTube

YouTube recently became a favorite place to hang out and learn. I’m finding tons of lectures and seminars on a range of topics from software development to health to cosmology. There’s literally millions of hours of presentations on virtually any topic you can think of, plus every album ever produced, concerts, events, and so much more on YouTube. And the YouTube app is great, keeping up with my many interests and suggesting videos on a range of topics that interest me. If only Netflix could tune in to my taste as well, sigh.

8. Calendar 

The calendar app that comes with iOS is simple, interfaces with my Mac and Google calendar, and lets me coordinate my schedule with my wife. It’s nothing fancy but it does the job and lets me schedule events.

7. Chrome 

Google’s Chrome is my browser of choice. It’s fast and simple to use. Safari is fine but I prefer Chrome, although I end up using both browsers when running under macOS. On Windows, I have a strong aversion to Internet Explorer and tend to use Chrome and Firefox. 

6. Music

Having 300-400 CDs is actually quite unmanageable so I was super excited to put most of my music collection in iTunes. I have about 11 days worth of music or 19 GB. Even so, I get bored listening to the same music so I listen to music online a lot. I love Pandora and Tune-In Radio. I’ve also found every album ever recorded on YouTube so that’s often where I’ve been going to listen to some of my favorite classic albums as well as tons of concerts that were never made into albums. 

5. Dropbox

Dropbox is definitely the coolest thing since sliced bread and it has transformed how I use computers. I’m no longer a slave to a particular OS. In fact, Dropbox let me make the switch from Windows to macOS seamlessly and without hardly noticing. All of my data files are instantly accessible from the other platform. I might even be able to live without a PC or Mac if Dropbox gave me a bit more functionality over managing files in iOS.

4. Duet Display

I’ve been having a great time with my 12 inch MacBook Pro and iPhone X. I couldn’t remember why I always went for the big screen laptops. And then I got back into coding. Trying to work in six windows at the same time can be challenging on a 12 in screen. Fortunately. There’s Duet Display that turns my iPad into a second monitor so I have the extra screen space I want when coding.

3. Editorial

Text editing is one of those things I find myself doing a lot and having a good text editor is essential for a writer. I have tons of “distraction-free” writing apps including IA Writer and Writing Kit but my favorite is Editorial for its great features, rock-solid performance, markdown support, and workflows.

2. Notability 

I bought this app when it first came out for $.99 and it was money well spent. This app is sold as a note taking aide and its great for that but I use it for several other key tasks. It holds my online library of hundreds of books on a range of subjects. I also use Notability to save, review, and store the hundreds of articles and papers on the range of subjects I’m researching at any given time. Sending any webpage to Notability turns it into a pdf file I can annotate and store for later access.

1. Frax

Frax is my favorite app and the number one reason I was burning to have an iPad. You may have noticed I didn’t list any games in my top ten iPad, iPhone, and macOS apps. I rarely play games. I do, however, explore fractal landscapes, sometimes for many hours every week. Frax opens the door to the animated world of fractals. It’s totally amazing and mesmerizing. I don’t quite know how to explain it but I’ve learned a ton about everything traveling through fractals. There’s a free version to check out at the App Store.

My first iPad was the iPad III and I was a bit reluctant to get it. That lasted for about ten seconds and I found myself constantly using it, even more than my laptop. After about six years I finally retired it and I just got myself an 11-inch iPad Pro. What’s so great about the iPad? The apps! I have many useful apps that I can’t run anywhere but iOS. These are my top ten apps but I have dozens more that I use all the time.

How about you? What’s your favorite iPad apps?

My Ten Favorite iPhone Apps

I’ve been a fan of iOS since I got an iPod Touch to manage my to do list and it ended up managing my life and my work with it. I’ve found several amazing apps for my iPad/iPhone/iPod over the years. Here are my top ten iPhone apps:

10. Phone

Yes, I occasionally use my iPhone as a phone. My preferred method of communication is email. Call me old fashioned. I’ve banished the phone icon to a folder that sits on my tray so it’s always two clicks instead of one click to make a call. That’s fine because I don’t make calls that often and when a call comes in I get interrupted and can click to answer. 

9. PowerPoint

As a road warrior who is constantly connecting to other people’s projectors, I’ve found that iOS devices are the most reliable for displaying slides in PowerPoint or Keynote. I plug in my iPad or iPhone and it works. I plug in my PC or MacBook Pro running Parallels, not so much. It really does depend but when things were flaky and that costs time so having a backup of all my slides on my phone I can use if my main computer fails has saved me many-a-time. Plus, you should see the look on the faces of Microsoft engineers when you project their course material on an iPhone.

8. Pomodoro (replaced by Flat Tomato) 

This is a simple little timer program that I find myself returning to again and again. It simply starts a variable timer whose intervals go: 25 minutes work and then a 5 minutes break, which repeats four times and then you take a 15 minute break. Each 25 minute work session is called a Pomodoro (after the red timer, I think) and a good day of work is completing eleven of them. I find that when I get up and move around during those five minute and fifteen minute breaks I can work for much longer periods of time without getting tired or burned out.

7. SleepMachine

When I am tired and ready to rest I use Sleep Machine to unwind and relax. It was one of the first Apps I bought for my iPod and I love having a range of high quality environmental sounds that I can mix and play in the background. I actually have several similar apps: Brainwaves, Binaural Beats, Relaxing Melodies, etc. And I find them really helpful, especially sitting at O’Hara Airport on a Friday night waiting to get on my flight home. At times like that it’s nice to remember a tranquil stream with birds chirping and water gurgling. 

6. Kindle

I recently discovered how great my iPhone is for reading books. I never tried the Kindle app because my wife bought a PaperWhite and found it hard to read. But the Kindle app on my iPhone is awesome, easy to see, easy to hold in my hand for hours, and easy to extract quotes from. I now love reading on my iPhone.

5. ProMovie

This app turns the iPhone X into a 4K video recorder with several professional features. This camera shoots Hi-Def and even 4K video with stunning clarity. It has an excellent control panel display and a range of manual override settings. Most notably, this is the only video app I found that allows you to override the auto-level control on input audio for sources you can plug in.

4. Google Maps

Like most people, my phone serves many purposes and GPS is a critical one for me because I have a bad sense of direction. I forgot all about my clenched fists around the steering wheel trying to read a map while driving. Turn-by-turn, and now with realtime traffic updates makes driving much more bearable. I like Google Maps much more than Apple Maps. Sorry Siri. 

3. Camera+

Now that I have an iPhone X with its 12MP dual cameras and 4K video capability, I’ve been doing a lot more photography. This is something that consumed me in my youth. Now that I have such awesome equipment in my pocket everywhere I go I expect to get some amazing pictures and HD video. Camera+ from Tap Tap Tap is one of the many camera apps I use to give me fine control over the pictures and videos I shoot.

2. Dictate and Connect

Now we’re getting down to it. These next two apps were almost tied for first place. I still use my iPhone as a phone, occasionally, but my phone icon is buried in a folder. The icon that sits in the lower right of my tray is Dictate and Connect. It is the best dictation software that I’ve found. It doesn’t do transcription, just recording but it does recording really well. It’s an integral part of my writing process.

1. 2Do

2Do is a task manager that offers some advanced features. I use it to manage all of my tasks. I’m not quite sure how people manage their work and their lives without a tool like this. To do lists and stickies definitely don’t cut it for me. At any time, I can be working on several projects and I have to be able to manage each one efficiently, 2Do let’s me do this.

Moving from my iPad for most of my writing back to my MacBook Pro and to my iPhone X for everything else that I used my iPad for is working great. Having a desktop computer in the palm of my hand sure is responsive and for the times I have to be away from my MacBook Pro it’s good to have a back up device I can carry in my pocket.

How about you? What’s your favorite iPhone apps?

My Ten Favorite macOS Apps

I’ve been a Windows developer since 1988. The version of Windows I started with was just called Windows. It was before Windows 286 and the popular Windows 3.1. Prior to that, I was an OS/2 developer and much of my code for the graphics system got consumed by Windows.

So, when I switched from Windows to macOS thirty years later it was a big deal, or so I thought. It turned out that nearly every program I depend upon has a macOS version. Now I run macOS application for almost everything that I do. I’m a Mac and I’ll never go back! So, here are my top ten favorite macOS applications.

10. Parallels

There are still a few situations I find myself in that requires Windows. Many of my clients use .NET and Visual Studio. Also, the accounting software I use only runs in Windows. Parallels lets me run Windows on my Mac and it works amazingly well. My last MacBook Pro only ran Windows under Parallels for the six years I owned it without any issues.

9. Skype

Since my computer tends to be in front of me most of my waking hours, I tend to use it for everything, including communications. I use a variety of video conferencing and screen sharing software when I collaborate. Skype is a good fallback since it tends to work well even under poor conditions. I also use Skype for making free outgoing calls most anywhere in the world.

8. TextEdit

I tend to use text editors a lot. In this case, because TextEdit works well with Dragon Naturally Speaking. There’s a noticeable boost in performance for voice editing. Aside from that, it’s a basic text editor.

7. Final Draft

Final Draft is professional screenwriting software. I’m a professional writer, after all, but I only dabble in fiction and screenplays. It’s more of a stress reliever than anything else but It’s nice to have a powerful tool for writing screenplays.

6. Eclipse

Now we’re talking more language. Eclipse for Java on the Mac works just like the Eclipse I know and love on the PC. All of my code immediately ran on my Mac just like it ran under Windows. It was great.

5. Sublime Text

It’s amazing how much I use my computer for dealing with words, but again, I’m a writer. And words come in a variety of formats such as HTML, Word documents, etc. But there’s always a need for dealing with plain text and my favorite plain text editor is Sublime. I’ve been anxiously awaiting Version 3 and love it on the Mac.

4. Dragon Naturally Speaking

This program I use all the time and it changed the way I write. It’s voice recognition and it’s finally at the point where it is useful. One benefit of Dragon Professional over the voice recognition software that comes built-in to the Mac is the ability to transcribe audio files. This is the way I like to use voice recognition. I find real-time dictation is too distracting. I rather speak what I want and then later go back and edit it.

3. Mail

Being an Outlook user from the Windows world I was pleasantly surprised with Mail from Apple. I use email a lot and I really like how Mail is laid out and works on my Mac. I also like the Filter Unread button so I see what emails are still marked as unread and I have to deal with.

2. Word

Microsoft Word is a standard worldwide and across many industries. There’s one main reason for this—it works! It may be bloated and a pain in places but it still has the best implementation of Track Changes I’ve ever seen and it has tons of features, and everyone uses it. I’ve recently upgraded to Office 365 for all my family’s computers. So far it’s only been painful during subscription renewal time but they make it as easy as possible for me to part with my money.

1. Scrivener

But Microsoft Word isn’t my preferred writing tool and the file system with Finder isn’t my preferred content management system (CMS). I use Scrivener as my ideal application for creating text well as managing and presenting text. A decade ago, I’d probably say Eclipse was my number one program but today I write more prose than code and Scrivener is my favorite tool for managing my most valuable assets—my words.

Having been a Microsoft Windows user for most of my life I was reluctant to switch to macOS but I sure am glad I did. I find most things much easier and more straightforward to do on my Mac. I guess it goes to show that if you own the hardware and the software you can provide a better experience to the user.

How about you? What’s your favorite macOS apps?

Announcing the Ten Year Anniversary of My Blog

Yes, it was on December 5th, 2008 that I wrote my first blog post. Over the next decade, I would write hundreds of posts on agile software development principles and practices. If you haven’t checked out this free resource, I encourage you to do so by visiting http://tobeagile.com/blog.

I’ve recently recategorized my posts so it’s easier to find information on specific interests such as TDD or refactoring. They say it’s best to give posts categories after your blog has been around for a while. I figure ten years is a while so it’s time to give posts more meaningful categories than “Rants” and “Bits and Pieces.”

With the nine new categories corresponding to the nine practices in my book, you’ll be able to look up blog posts about subjects you care about more easily. I haven’t done away with old categories. If the post is geared towards management or process then it’s a “Rant” and if it’s more technical or developer-centric then it’s a “Bits and Pieces.” You’ll find the new Category dropdown in the sidebar on every one of my blog pages.

Right after the New Year, I’m launching a new series of blog posts based on the “Seven Strategies” sections from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software (http://BeyondLegacyCode.com).

Each of the seven strategies is another post, which lets me go into much more detail about each strategy. I’ll go through the first set of Seven Strategies for each of the nine practices in my book, plus an introductory post for each practice. That’s a total of 72 posts! That’ll keep us busy for a while.

On January 2nd, I’ll write a post introducing the category based on Practice 1, “Say What, Why, and For Whom Before How” followed by a series of seven weekly posts on each of those seven strategies. After that, I’ll follow the same pattern for Practice 2, “Build in Small Batches,” and so on.

Don’t worry, I’m still here and will continue to post on other topics as I see fit. I just want to make sure there’s a weekly stream of ideas flowing to this website for you to enjoy. It’s all automated, so don’t worry. No matter what happens in the future, I’ll be seeing you right here until at least 2020.

And over these next three weeks before the New Year, I have something special planned for you, although a bit off topic. I’m going to share with you my ten favorite apps for macOS, the iPhone, and the iPad. These thirty apps are among the most useful software I’ve found and I’m excited to share them with you so stay tuned, we have an exciting time coming up!

And for even more from me, sign up for my monthly newsletter at https://tobeagile.com/signup and follow me on Twitter at https://twitter.com/ToBeAgile.