Google’s latest technological innovation is Google Tap. They’ve taking touch screen input to a new level by reducing everything to two buttons. Enhancements to predictive text, audio feedback, and ship-to-shore communication have brought telegraphy from the 1840’s to fast fingered smart phone users of this century.
Android users can hear their contact names played in Morse Code using the Morse Names App.
After some testing, I’ve finally got my first Android app out on the Android Market. It isn’t showing up in the search just yet, but it should be by tomorrow.
Morse Names will play morse code tones for your contact when you receive an SMS.
Feel free to share the following link with anyone who would like to purchase the app:
You may also visit the development page at:
Thanks again for all the testing, help, and ideas and let me know what else breaks or could be made better!
One of the biggest challenges with my current position is that there is a lack of buy-in for Agile. My company has decided that Agile is a good thing and is working toward introducing it to all developers. Agile really does not lend itself well to a top-down implementation. Given values of self-organization, shared concerns, and organic process, it feels wrong to force feed it to developers.
The team I work on gradually built up its current set of practices as a team. Things were introduced gradually and we learned quickly that small, incremental change was more effective than unilateral, sometimes arbitrary directives. We spent a lot of time working with the stakeholders in our company to explain what we were doing, why we were doing it and getting them involved in the process. We were not always successful our first time, but we managed to evolve as a team and to make things work successfully.
In contrast, top-down directives move very slowly through a company. It is much easier for a small group of developers to say “Let’s do a quick standup meeting every morning” than it is for a C?O to say “Here is Scrum. Learn this and use it.” Top-down directives start out vague and expect the Org Chart to figure out what is meant by the directive, to create a plan, and to implement it.
This is a non-starter in my eyes. If you ask an established PMP/Waterfall/Big Design Up Front person for a project plan to implement a new process, you are going to get exactly what they are used to giving you. They are going to spend a lot of time and energy designing a plan for a bunch of processes that may or may not work. The plan very well could be the best plan ever and completely work, but are you willing to bet your whole company on it?
One of the biggest problems I’ve seen with this approach is that there are not solid relationships established between different aspects of the company. If your sales, customer service, and professional services teams are not on the same page as your developers in terms of incremental release, product ownership, transparency, and tight feedback loops, you will have difficulties.
One of the advantages of already working with an agile mindset is that I believe that by “embracing change” I can help overcome these problems. I don’t mind the fear in a salesperson’s eyes when I ask if I can speak directly to a customer. I look forward to learning what it means to “capitalize” a software product as an asset. I enjoy listening to customer service people explain their problems to me and finding ways to help them out. This is what I do as a software developer.
At the end of the day, I’m glad that the company has decided that the way I’m already doing are things that should be considered best practices. I am thankful they are finally catching up.
One of the problems to solve for any development shop is how to keep track of what you ship. Each version of software that you release has a set of changes associated with it. How do you manage all the changes so you know which versions of which files are in any given release?
A solution that we use at my current employer is to combine a Release Management Database with a Version Control System. We use tags in our version control system to track what is in development, what will be shipped, and what has shipped. We have pushed this system as far as doing monthly releases with our enterprise application. I’ll do my best to describe our process for you.
We are an Agile development team, so each feature we choose to implement or each defect we find in the software is managed by a User Story. We document these stories in the release database. Each documented story has a description of the change, testing criteria, implementation notes, etc.. When a story is created, it is assigned to the current Iteration (release). We do not permit stories to be associated with previous releases of the software.
The release database scans the version control system for changes. When it detects a code change, a developer is allowed to associate that change with a particular User Story. When a code change is associated, it is tagged with an ID for the User Story as well as an ID for the Iteration. What you end up with is the following:
Looking at these tags, we can see the history of the changes for this particular file. Release 124 shipped with version 1.81 of the file. I can see that version 1.81 also has the tag FEATURE_9392, which I can look up in my release database for further information or I can search my version control system for other files with that tag. I also see that releases 125 and 126 also are associated with version 1.81 of the file. This means that no changes were associated with it for those two releases. For release 127, version 1.83 is shipped. I see that versions 1.82 and 1.83 were both associated with defects 820 and 828 in our release database. Also of note is that versions 1.84 and 1.85 of the file have been checked in, but are not yet associated with a change. That indicates that a developer has not yet finished work on a feature or defect for the current iteration.
We use a Continuous Integration system to build and test our software. Whenever a change is checked in to version control, a build is started. The build compiles, packages and executes unit tests on the software. The build that is executed for each change retrieves all files tagged as HEAD from the system. We also have a nightly “integration” build to package our software and run additional tests. This build retrieves all files tagged for the current release (i.e. ITER_127), compiles and packages the software for us. In theory, this release should always be shippable as long as the integration tests pass.
This system has served us well for a few years, but it does have its weaknesses. Patches are tracked outside this system. We do not believe that patches are a good way to manage software, but in reality, we do have to do them. We make sure that any time one of our customers does require a patch for an older release that we first integrate the fix or the feature into the current release, then work backward to determine what needs to change to make it work with the older release. It isn’t always easy, but as long as you have a well documented set of changes, it usually is not too difficult. We could likely create a new tagging mechanism that would allow us to track patches as well, but given that we do maybe ten of them a year, it hasn’t been necessary.
Using this method, it is easy for us to have access to any particular build of our system. If a customer upgrades from release 247 to release 249, we can use our version control system easily see differences between our ITER_247 and ITER_249 tags. Once we see the differences, we can refer to the release database for the details in the stories associated with those changes.
We use this system to track code changes, documentation changes, and configuration changes. Everyone from our developers to our QA staff to our managers are familiar with how the release database works, even if they don’t understand the ins and outs of our version control system. This method could be extended to allow for branching with the addition of more tags and a solid branching strategy, but that is a topic we’ve managed to avoid quite happily.
I have spent the last two weeks brainstorming and discussing my ideas with friends and random strangers. When you try to explain your idea to someone, you usually get one of three reactions:
Wow!
If someone is genuinely WOW’d by your idea, you might be on to something. You need to make sure it isn’t a superficial “I’ll stroke your ego, my friend” type of wow and you need to make sure that what they are hearing is really what you are trying to say. If you cover both of those bases, you should look further into this idea. Wow! is good.
Oh, no, no…
This is probably bad news. They don’t like your idea. Why? Are you explaining yourself well? Have you not thought things through enough? Does this person have a bias or some kind of general dislike for your subject area? Perhaps your idea just isn’t a good one, but understand why this person does not like it and weigh it against other opinions and further research. Accept criticism, but don’t be afraid to reject opinion.
Huh? I don’t get it.
Assuming you are talking to a reasonably intelligent human being, either you have not been thorough enough in developing your mental first idea draft or there is a disconnect between your brain and your mouth and you just aren’t communicating well. A person who doesn’t “get it” is one of the best people to work through your idea with. They can point out holes in your concept, get you to clarify your thoughts, and at least make sure your general idea makes at least a little bit of sense. Keep working on it.
I’ve also reached out to several trusted friends and asked them to join my personal advisory board. I have a very smart and supportive group of cronies who graciously have accepted, I just hope they know what they are getting in to! I plan to do a monthly email/newsletter to share my progress, ask questions, and solicit feedback.
Productivity tends to come in waves. There are days when I can accomplish an entire days worth of work in an hour or two and there are days where I can’t accomplish even the most simple of tasks. All in all, it probably averages out over the course of a week, month, or year, but there may be something to be said for keeping yourself more consistent.
Productivity is how much you put out relative to how much you put in. If you are a widget maker, you can measure your productivity in widgets per hour. If you are a software developer, you may measure yourself in lines of code per day or features per week. There is another element to productivity that you must consider. If you are capable of making 100 widgets per hour, what would happen if you forced yourself to double your output, but keep the same number of hours? Quality would degrade. Can you afford to sacrifice quality for quantity? The answer is a definite maybe. If you make red, blue, and green widgets, could you increase your output if you only made red widgets? Would you save time on setup, packaging, quality control if you limited the scope of your production while still maintaining the quality of your red widgets? Generally, I would think you would not want to sacrifice quality for productivity. It is probably counter-productive in the long run.
With summer winding down, I have had to limit the scope of my projects in order to maintain my quality. I have had too many yard projects, summer social events, and birthdays to maintain a high level of output with an appropriate level of quality. The frequency of my blog posts reflects this. I feel alright about this because I made a conscious decision to work on things that I could get done well in the time I had to do them. However, I do need to create a series of self-imposed deadlines and milestones that I can match up with my goals. While I have been generating output, I need to be sure I am generating the right outputs for my goals. I would like to create a set of personal productivity metrics that I can track for the long term.
Problem solving is complex. It is something that we all pretend we do naturally, but on average, humans are not very good at it. In order to be an effective problem solver, you need to divorce yourself mentally from problem. You need to be able to identify and understand the present condition, define a more desirable situation, then work out the path between the two. Each of these three activities requires higher order thinking because not only do you need to understand the domain and context of the problem, but you also need to understand the meta-context around it so you can evaluate, realign, and manipulate the defining factors to your goal.
I believe that most people have difficulties with the initial investigation of a problem. In my experience, the greatest difficulty stems from that inherent attachment people have to their problems. You may be too physically, mentally, or emotionally invested in the situation to be able to objectively evaluate your position. Fortunately, the Scientific Method gives us a number of techniques to investigate and evaluate a problem. The basic process is as follows:
The Scientific Method does not inherently solve problems, but once you have used this method of inquiry to understand your problem you can then move on to solving it. Before you can actually reach a solution, you have to understand what you are trying to accomplish. If you’ve developed and proven a hypothesis that your customers are unhappy because they are missing a key feature in your product, you need to define that key feature before you can determine a path to deploying it. Airplanes do not leave the airport without a destination and a flight plan. The flight plan can be flexible, but the destination is usually fairly rigid. Business goals probably change more often than flight destinations, but the general concept still applies.
There are many methods of problem solving including abstraction, brainstorming, reduction, lateral thinking, root cause analysis, and even trial and error. I will explore some of these methods in future posts. Whatever metaphor, process, or methodology you use, they all have two common points. You start with a definition of your problem and a vision of your desired outcome and you figure out the path from Now to Then.
In order to be successful, you must have an effective support network. While we all want to be heroes and to do everything ourselves, it is just not practical. There are many different kinds of support that we may need to call up at any point in time.
Life Support
There are many things that we just can not do without in life. Maslow’s Hierarchy of Need tells us that we need things like food and water, but it also reminds us that things like intimacy, respect, and self-actualization are important. Without the support of our friends, neighbors, and communities we are nothing. Our families are absolutely critical for success.
Moral Support
Emotional and psychological backing is important. You need to surround yourself with people who believe in you, but also people who you trust to keep you honest with yourself. When you lose a little bit of faith, there is nothing like a friend to pick you up, dust you off, and kick you in the butt to get moving again.
Technical Support
Specific problems call for specific solutions. When you have a problem, you can go to an organization designed to give you domain specific support. The Genius Bar at an Apple Store, a customer service representative at your bank, or a poison control center can all bring a quick solution and instant expertise to help you sort out a problem. Not all support resources are free, but some are well worth paying for.
Structural Support
I am a big fan of automating as much of a business as possible. I believe that businesses should focus on their core competency and not be distracted by things like accounting and HR. These things are critical to running a successful business, but they are also easily handled by resources outside your nuclear core of productivity. If you need to do something in-house, by all means do it, but I bet you don’t for most things. Outsource (or automate internally) redundant/commodity tasks.
Peer Support
No matter how unique your ideas may be or how much of a genius you think you are, you are probably not the only person with your idea or something very similar to it. The power in most ideas and inventions is not in the individual idea, but how it relates to things that already exist or what does it may open to future opportunities. There are many people around you to bounce ideas off of, to ask for help, to offer help to, to partner with, to compete against, to build a community with. Ideas are much more powerful when they are combined with the collective wisdom and resources of your peers.
No man is an island, and no island is an archipelago. We all have a massive amount of support and structure that we lean and build from every day.
One of my favorite things to remind myself when I get really busy is, “I can do anything, but I can’t do everything.” There are only so many hours in a day where you can be productive and get things done. In order to be successful, you must constantly make decisions about what the most important thing to work on is, right now. If you aren’t working where you are most needed or you aren’t working efficiently, you should be looking for opportunities to distribute your work. If you are able to bill yourself out at $200/hour, what is most important? Should you be doing your laundry or doing billable work? You can pay someone else to do your laundry and still be ahead of the game…
As you build a business from scratch, it becomes very important to understand your personal strengths and weaknesses. If you can fix a weakness, fix it and move on as efficiently as possible. If not, develop a resource to handle it better than you can yourself. There may even come a point where it may be better for the business for you to do nothing at all. This is not necessarily a bad thing! It could very well mean that you have automated your business to the point where you can just let it run and pick up your wheelbarrows of cash. Better yet, pay someone else to bring them to you!
Always ask yourself two questions as you work. Is this the most important thing for me to work on right now? Even more importantly, do I need to do this at all?
There are multiple things that I have considered doing for work. I have quite a few ideas and I’ve tossed many aside. Out of the ten ideas I have a week, maybe one will be appealing to me. Periodically, I will compare and contrast these ideas to see if anything really stands out. Now that it is time to pick up the ball and run with it, I need to decide which game to play.
I plan to use the concept of the wireframe to quickly assess the viability of each idea. A wireframe gives you a loose idea of the structure and mechanics of a project without actually implementing them. They make it much easier to visualize your ideas and allow you to look for strong and weak points that you might miss without something slightly tangible. By doing a quick wireframe for each idea, I can sit down with several of them and make decisions about which ones to keep and which ones to remove.
I plan to build a wireframe for the business as a whole, not just the products and services. In order to do this, I will need to understand the basic mechanics of a business. I will need to make sure that what I produce can eventually be extended into more traditional business plan. The wireframe should give me a description of business and the product, an overview of the market, an idea of the people and resources I will need, a general idea of the day to day operations, an idea of why it might fail, and a reason to do it all.
Wireframes make great artifacts. After you do a few of them, you start to notice similarities between them. Sometimes you can take parts from one and plug them into another. It will be interesting to see how much of this process I can automate after I’ve done a few of them.