All posts by John Beauford

Development, Software Development, Technical Debt

Keep – Buy – Steal or Build – The 4 mechanisms of software system replacement

Leave a comment

So your business has a software system or software project that needs some attention.

Maybe there is pressure or need to replace the software system  altogether.

The reasons for replacement or update can be varied. Maybe it’s scalability, security, usability, or features. It could even be due to maintenance issues or a business need to change the architecture.

Whatever the reasons behind it, you have a decision to make about how to move a software system to a better place.

How do you decide what level of investment / work to do?

1. You can keep the software you have

Remodel or refactor the software

Refactoring is a way to make incremental changes or add iterative improvements to a body of software over time without replacing what you have.

Refactoring software is like repairing a boat as you sail across the lake. You make small changes so as to keep the boat afloat and not sink it.

By refactoring you keep the usage, benefits and revenue of the existing system but iteratively improve what you have. In most cases, it’s lower risk and can be less disruptive and lower cost.

An adroit team of developers can identify and iteratively improve an existing system surprisingly quickly. This mechanism can breathe new life into existing code in less time, with lower risk and a far more predictable schedule that the full replacement options listed below.

Depending on the level of need and the root issues this may be a viable option. However, you the situation warrants it, you may have to replace.

2. You have to replace the software you have

At one large company I was at years ago, our VP was known for responding to requests for software development resources for new projects with the following paraphrased response: “First we steal, then we buy, then we build”.

By his response, he was showing the truism regarding internal software development economics.

Reuse is cheaper than buying.

Buying is usually cheaper than building and maintaining.

If for business or functional or support reasons you have to completely replace what you have, there are essentially three options.

Steal

This is a metaphor for reusing software from another project or system within your company. It’s also called creative re-use.

If you have multiple projects or programs, one may have the software foundations already in place for what you need. Reusing or repurposing that can take less total effort and risk than standard replacement methods.

Buy

At this time in software development history, there are commercial options for almost every business need. It is worth it to look at your requirements and scan the existing universe of commercial software to see if there is an existing fit. This method can reduce time to market or reduce time to reap the benefits of having the system.

Build

Nothing exists that you can use for the need you have.  Or maybe what exists so prohibitively expensive or not a fit for your needs. If you don’t have anything laying around to reuse and you can’t use what is available on the 3rd party market, you must build it.

If you have to build it there are a lot of considerations to make.

  • Internal vs external team
  • Tech Stack to use
  • Specific external libraries or 3rd party services to use
  • Architecture
  • Development Environment
  • Deployment Environment
  • Non-Development Resources

If you decide to build the software internally also consider the ongoing maintenance costs after initial release that will be associated with hosting, updates, training, security patches, environment, and feature improvements.

So What

By considering all the available options a business has regarding software replacement, including re-factoring, an owner or sponsor improves the odds of the best decision for the company.

 

Development, General IT, Leadership

5 reasons to attend a tech conference near you

Leave a comment

It was the first tech conference I had attended in years. And waiting this long to attend a technical conference was a mistake.

Last week I had the opportunity to attend the ITRoadmap conference put on in Fort Worth, Tx. by the fine folks at IDG.

I enjoyed a well-paced day of keynotes, panel sessions, vendor presentations and tutorials.

I had breakfast and lunch with very interesting groups of people and discussed relevant current issues and found out how they are dealing with them.

I even ran across 2 guys who live very near me that I had never met before.

I spent time discussing culture issues with one of the panelists on the “Best IT places to work” panel. He gave me some great ideas regarding culture and employee practices to improve engagement and retention.

I left the day refreshed, better informed and motivated.

So here are my 5 reasons you should attend a conference near you.

1. Meet new people in your market similar to you

As an IT and software development director, it was enjoyable and informative to meet the same type of people who work in my geographical market and get to know them and their business.

I increased my network, made new friends  and learned new things about some of our local businesses.

It was good to hear how those folks are dealing with some of the same problems I have to deal with. I walked away with new ideas.

2. See new perspectives on the same problems you are dealing with

The tutorial sessions and vendor presentations were well done and educational.

I learned something new in every session I attended.

I walked away with new techniques to try, new tools to investigate and new acquaintances to further my reach.

3. Form connections for future business or collaboration

I made connections to people and businesses that will help me in the future as well.

I learned about some new tools from Dyn that can help us with product delivery to our customers.

I came away with new DevOps strategies from Irwin Lazar, Vice President of Nemertea Research.

Dean Shroll of Sophos gave an interesting and scary talk about ransomware and the current threat landscape.

And I met some folks who work very close to me that I can continue to develop friendships and learn from.

4. Explore more in-depth industry trends and issues

Here are just 3 small examples of the talks and tutorials that were given.

Derek Hulitzky provided a talk with 3 short case studies of companies that have made profound digital transformations their business.

Mikel Steadman, Director of Sales and Solutions Engineering at Dyn gave a fascinating talk regarding doing business on the internet and provided some perspective on the recent DDoS that Dyn suffered.

Nicole O. Fontayne, Vice President, Chief Information Officer for  DART described how they deal with the enormous IT complexity of a metro area transit system.

We learned about the trends in hiring, retention, IoT and cloud migration and scaling, DevOps, Security and tons of others.

5. Find a new job

And yeah, you can also find folks who have businesses that need people like you. It can be a recruiting (or hiring) bonanza depending on what you are looking for.

Conclusion

It was so worth missing a day of work and the pains that come with that to attend the IT Roadmap conference. It was a great benefit to me and I will sign up as soon as registration starts next year.

So go and find a good conference near you and attend, and participate. You will be glad you did.

Development, Software Development, Technical Debt

4 ways every business is increasing technical debt and how to change that

Leave a comment

We all like to think what we do helps move our business and products forward.

But………

Sometimes subtle, embedded habits and tendencies we have actually increase the rate at which a business accumulates technical dead. Which of these does your business have?

Short Sighted Executive Decisions

You have been in those meetings.

You know the meeting, where the executive in charge slams their hand on the table to get everyone’s attention after an extended debate.

And then, with red face of anger and the decibel level of a 747 on takeoff, bellows “this product will ship on time“. 

This display is usually accompanied by promises of some sort of employee  retribution if the fantasy date is not met. It is at that point the meeting is really over and no one will dare raise any additional points no matter how real and urgent they are. 

Using emotional outbursts to attempt to motivate a team doesn’t create technical debt per se. However, it is the short-sighted executive decision making that results in this environment will create technical debt.

There may be valid reasons why the product can ship on time. However, there may be serious issues, just under the surface, that could cause the company big problems if the ship date is met.

Astute executives ask penetrating questions, validate assumptions and create productive dialog. Click To Tweet

Astute executives ask penetrating questions, validate assumptions and force the analysis and discussion that create productive dialog. It is only in an environment where subordinates and colleagues feel safe in disagreeing or bringing bad news that all issues can be on the table and then dealt with appropriately. Otherwise, things that could be real issues get covered up, hidden, or ignored. And when issues and technical debt builds, are you can rest assured they will pop up later at the most inconvenient time.

Management Short Cuts

Typically managers take short cuts that build in technical debt for two reasons: 1)because they are incompetent or 2)because they are trying to make points with the boss by finishing earlier, cheaper etc.

Incompetent managers yield all kinds of pernicious evil in software or IT implementations. They can hire the wrong employees, force inadequate or inappropriate implementations, misunderstand technical requirements, force the use of the wrong tools or rewarding the wrong behaviors. The results of these managers will always cost more, take longer, disappoint, and need large corrective actions.

The brownie points gang are those managers that always want to have the right answer.

“Yes we are on schedule”

“The project is coming in under budget”

“Yes we can add those all those new features” 

“No, that change won’t affect our delivery capability”

Looking good is more important than reality and truth. These types of managers are skilled at making themselves look good and figuring out some other person, group or division to take the fall when things hit the fan.

Adroit managers work to always increase their competence through training, assignments, asking questions, checking assumptions and working closely with their teams. They understand that by continual growth and disciplined execution they will impress their bosses and it will be real.

Developer  Laziness

I was recently working on some software and came across a whole section of code that had been copied identically and only a couple of  lines changed to accommodate the different situation. This is a perfect example of developer laziness. Instead of taking the extra mental effort and time to create a method to do the work so that it was encapsulated in one place,

This is a perfect example of developer laziness.

Instead of taking the extra mental effort and time to create a method to do the work so that it was encapsulated in one place, technical debt was created by copying a bunch of code unnecessarily. It may have allowed the developer to quickly get work committed but built in a headache for someone else to deal with later.

Skilled developers understand when small refactoring can save huge time later. Click To Tweet

Skilled developers understand when small refactoring can save huge time later. They know when it is worth it to make additional small investments to avoid bigger problems later.  Invest in resources to train developers on your systems, standard coding best practices, and effective coding refactoring processes.

Team capability

What’s your team training plan look like?

Do you cross train?

Are you encouraging them to learn better methods of coding or testing or implementation?

Are you giving them tools to improve code, deployments, or testing?

Is continual learning part of your culture?

If you don’t have answers for these questions for your team or yourself then you could be inadvertently building technical debt in future implementation.

The technology software and IT is advancing at an ever increasing pace.  Your organization has to adopt an adaptive, learning mindset to stay up with advancements. And incorporate them to give your business advantage.

Improving teams create and execute training plans for the tech they are involved with. They set expectations for learning, growing and utilizing what they learn to improve products, productivity, and performance.

 

General IT, Product Management, Software Development, Teams

The two warring tribes within small business IT and software development and how to make peace

Leave a comment

Lisa Jaspers LinkedIn article struck a chord. She identified a huge issue that affects any small business IT/Development team that is tasked with BOTH maintaining existing systems as well as facilitating new product development.

In small companies, usually a single team has to do both existing system maintenance as well as new product development. This duality can  create a “two warring tribes” atmosphere. And as Lisa states in her article, you can’t just add roles here and there and solve the problem.

Sometimes the warring tribes exist inside the individual as they feel pressure from both camps to do different, yet equally urgent, work. Sometimes they exist as 2 groups of developers within the same team, competing for resources, priority, or direction.

Warring Tribe #1: Maintenance Tribe

Your existing systems, software, and products carry the company. They pay the bills, enable the work, and serve the customers.

But, over time, these systems require patches, bug fixes, updates, security changes, regulatory modifications and customer feature additions. Maintenance, support, and caretaking of these systems can consume a small team.

It’s like your company is in a boat in the middle of the ocean and the boat is made up of the existing systems and products. Any leaks or issues with the boat have to be corrected quickly lest you risk the boat beginning to sink. This is existing system maintenance. Yeah, small leaks can be ignored for a while. You can hire more folks to ‘bail water’. But in most cases existing system maintenance issues will soon trump new product developer in time and dollars.

Warring Tribe #2: New Product Tribe

New product development, on the other hand, is like building a new boat, while you’re still in the old boat, without sinking either boat.

When there are existing product or system issues or urgent features needed for the paying customers, you pull your team out of the new boat and back into the old boat. When existing maintenance furor dies down the team heads back to the new product and continues on. This back and forth focus shift is more expensive than you think. It causes both tribes to suffer. And it causes the results of both tribes to suffer.

Influences on Tribal membership

When I was a developer, getting picked to go build the “new thing” was special. It was like getting drafted in the NFL. Or like getting asked to the prom by someone you really liked. You were desired and worthy of helping accomplish an important initiative for the company.  Getting “left behind” to continue to maintain systems was not as desirable. You got to sit out the prom. No dancing for you.

However, for others, who had key hands in building an existing system, they wanted to stay behind and continue to nurture their ‘baby’.  They had little desire to go and build something new.

In a large company setting, an engineer may get the flexibility to choose. And some engineers can do either.  But in a small company setting, you don’t always get that choice.

The same tension between  doing something new, or staying behind and shepherd something current, also affects project managers, QA folks, DBA, system admins and other roles within the team.

Ways to make peace

1. The two team approach

If you have enough resources you can divide and conquer to some extent. Pick those who want to go and help out with the new thing and allow them to focus on that exclusive, leaving those in favor of maintaining the existing systems in place.

I have seen this method work well.  Small, competent, focused teams can make progress very quickly. In the end, this is probably the most desired approach as Lisa Jasper shares, “because product development is such a different mindset“. A dedicated team can focus on new tools, new processes, different vendors and the different mindset needed for new product development without distraction.

2. Bring in the reinforcements

Another approach, if your new product development takes too many of your resources is to strategically contract for necessary  bug fixes and feature work on existing systems. Using this approach can help minimize cost, focus effort on only the most important issues and help keep you from ‘gilding the lily’ on existing system improvements.

If your existing systems have a lot of baked in technical debt the outside, tactical contractor engagement may not make sense. The success of this approach hinges on finding a reliable contractor who is familiar with your tools/framework/languages or systems. If this is the case then tactical contractor engagements can be very useful.

The success of this approach hinges on finding a reliable contractor who is familiar with your tools/framework/languages or systems. If this is the case then tactical contractor engagements can be very useful.

3. Bring in another army

If your team is small and they don’t have the experience or knowledge in the  domains of the new product then you can consider outsourcing the new product development.

In one engagement, in the earlier days of the app store, our team was building and maintaining web applications and needed an iPhone app built. Our team knew databases and the languages and frameworks we used but none of us had any real experience with iOS or ObjectiveC. So after some research and comparison shopping, we went with a third party company that specialized in mobile app development to develop the app for us. If your new product need is specific enough this method can work well.

If your new product need is specific enough this method can work well.

4. Refactor

Another approach that is not as glamorous, is to refactor existing products. This is especially true in software. In software, refactoring refers to the process of re-structuring software code to improve its operation and add or take advantage of new features that could not be done in the prior state.

If your new product needs can be broken down into smaller more atomic features, it may be possible to use your existing team and refactor your current product to add certain aspects of what a new product would bring. In the end, this may be a less costly approach overall and bring incremental improvements online faster.

Pass the peace pipe

There is no one size fits all solution.

Each company and situation are different.

By taking the time to contemplate some of these options you may be able to come up with a new and creative approach that will enable you to deliver a great solution within the constraints of your team and budget. The strengths of your team, time to market needs and existing product structure all influence this type of decision.

But in the end, recognize the pulling forces between the two tribes and the different mindset required for new product development. If you do this you are well on your way to a more successful engagement.

Employees, Leadership, Teams

6 P’s of really bad leadership OR don’t inspire your employees this way

Leave a comment

Bad leadership can be highly inspirational. It inspires anger, mutiny, frustration, confusion, abandonment, resentment or just plain old apathy. All of which, negatively affect your business.

Use the 6 Ps below to see if you have any of the highly inspirational traits. And find out alternative mindsets for change.

Patronizing

When leaders patronize their team they are sending an implicit message that they don’t believe the team knows what they are doing. It is a message of superiority on the part of the leader. It’s saying “I’m smarter than all of you”.

Patronizing your team chokes the flow of ideas and communication. No one likes being spoken to in this way. It makes you feel like a child and generates resentment. Do this long enough and folks will stop ‘having your back’. That can expose the leader’s blind spots in public and sometimes embarrassing ways.

Smart leaders will use tone, words and body language that encourages dialog and ideas.

Pontificator

A close relative of the “Patronizer” is the pontificator. A pontificator expresses themselves in such a way as to convey that they are always right. And usually, they do it in an overly long-winded dialog. They may allow conversation and listen to other ideas. But at the end of the discussion they make it clear through their speeches that they are the ones who are correct.

This too, is a habit that limits real communication. It makes people zone out. It encourages your team to go through the motions. It undermines team effectiveness. Why bother fighting for a great idea when you have to be brow beaten with long winded diatribes about why your idea is not as good as the pontificator’s idea? People will give up.

Observant leaders will carefully structure their words. You as the leader may be right. If so, then communicate clearly why. Succinctly list reasons or constraints that eliminate other ideas or courses of action. Invite dialog. Explore counter arguments. You may well be right. Or you way well learn something new.

Platitudes

Leaders with nothing substantive to say often resort to platitudes. These statements are worn out cliche’s that have little or no value in the business context in which they are said. They are said so much they are meaningless.

Phrases such as “It is what it is“, or “You never know what might happen” are worthless. Jeff Haden has more great ones in this article.

Resorting to platitudes during a time when real debate, discussion, and collaboration is needed on hard issues will evaporate the confidence of your team in you as a leader.

Effective leaders don’t waste others time with meaningless phrases that serve only to derail substantive discussions. They speak clearly and concisely directly to issues, allowing their team to fully participate.

Petulant

So what happens when you don’t get what you want?

Maybe the software release is going to be late. Maybe you didn’t get the contract. Maybe marketing rejected your ideas on the new website.  Maybe the CEO rejected your product plan.

Do you react in anger? Do you throw a fit? Do you lash out in rage on unsuspecting subordinates when they had nothing to do with the issue?

If you react like this, you are a petulant leader. Think of a three-year-old not getting the toy they want, falling down kicking and screaming. Yeah, you’re an adult version of that.

Having a public negative reaction undermines confidence in your leadership and will cause employees think twice before bringing bad news to you. The bad leadership behavior clogs up the communication pipeline.

Good leaders understand that things don’t always go your way. They react professionally and use these times as learning opportunities. They focus on what improvements they can make when bad things occur.

Pretender

The pretender always seems to have done great things…somewhere else. They can regale you with stories of great business prowess from yesteryear. They are always they one who saved the day, rescued the sale, figured out the bug. They always have accomplishments that no one else has heard of. Pretenders spend more time in the neighborhood of make believe than they do making people believe in whatever they are doing.

The pretender knows the jargon but comes up short on execution and results. Excuses yes, accomplishments, not really. Pretenders are impressive at first glance but with any probing, you see quickly how shallow they are. And pretenders are highly skilled at pointing the finger of blame somewhere else. They wear Teflon jackets.

Fred Brooks said it well in The Mythical Man Month:

“In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment”

Pretenders may have titular authority, but true influence comes from results. Eventually, the pretenders have to move over for those who actually get things done.

Authentic leaders inspire more devotion because their words and actions reconcile.

Parsimonious

These are the leaders that will choke every last cent out of an organization. No toilet paper is cheap enough. No coffee is too watery tasting. No office supply cabinet is too bare for their tastes. Spending the tiniest amount of money, even on absolute necessities, is like pulling wisdom teeth without anesthesia.

Certainly, keeping a judicious eye on expenses is prudent and desirable. But if getting you to spend any money is harder than prying food from the hands of a starving man you are misguided. If you cling to every cent and are so maniacal about costs that you won’t buy sugar packets for the coffee machine you are missing the bigger picture.

There is a balance between expense control and putting out a few bucks to improve the business or treat the employees from time to time.

Balanced leaders know a little spent here and there can go a long way to adding fun,  improving morale and generally making people enjoy the environment more. All of which are shown to improve productivity and engagement. Happy employees are proven to take care of customers  far more effectively than their sad sack counterparts.

So What?

If any of these behavioral attributes ring true for you, the first step to change is admitting you have a problem. If you have leadership tendencies from this list know you can change your habits. These traits may not in singular cases cause you big problems but they all subtly undermine your leadership and effectiveness if the behavior is engaged in on a regular basis.

If you are an employee and see these attributes consistently in your leader or leadership team then it may be time to polish up that LinkedIn profile.

Maybe this was what Grandma was talking about with the admonishment to “mind your P’s and Q’s”.

General IT, Technical Debt, Uncategorized

7 Areas of Hidden Technical Debt That Increase M&A Costs

2 Comments

This article first published at the Axial Forum here: 7 Areas of Hidden Technical Debt That Increase M&A Costs and is reposted here with permission.

Effective buy-side deal teams are well-versed at issues during due diligence that might impact a deal. But even the most astute deal teams can miss te­­chnical and IT aspects of the target company that can significantly impact the cost of the integration and the return on the investment.

Here are seven often overlooked areas of potential hidden technical debt that acquirers should investigate prior to close.

Employee Devices

Desktops, laptops, mobile phones, and tablets are the tools of the modern office worker. In most businesses each employee has at least one of these and in many cases 2 or 3.

The acquiring business will assume responsibility for the condition and upgrade/replacement policies for these devices. Even in a small company acquisition, there can be hundreds of devices to track, maintain, update, replace, or discontinue. A well-run business should have an inventory of employee devices.

During due diligence use this inventory to determine if excessive technical debt exists in the device fleet. If the business does not have a device inventory, further due diligence investigation will be needed to determine hidden costs.

Backend Server Hardware

Most businesses still use physical servers. These could exist in a rented data center or be stacked up in the closet down the hall.

As an acquirer, you need an accurate list of these assets and the purpose they serve. The actual server hardware needs to be checked for age, serviceability life, warranty, general condition and need. A server upgrade can be a non-trivial task, especially on a mission critical application. Factor in the costs of migration, updates, and maintenance of these physical assets in due diligence planning.

Server Operating System Patches and updates

In addition to physical hardware inventory, the operating systems of the servers need to be checked. Operating system vendors like Microsoft, Apple, or Linux issue updates to correct software defects and security vulnerabilities. It is up to the system administrators to keep up with the installation of patches and updates. Systems that have not been patched are more vulnerable to penetration and disruption.

Spend time during due diligence inventorying the operating systems’ patch level and the security vulnerabilities of the servers. Then plan for additional time and effort post-integration to mitigate.

Unsupported/Obsolete Software Applications

Some businesses rely on older software applications, sometimes custom-built. Old or obsolete software is a significant cost factor when planning mergers of technical assets.

During due diligence, inventory all software in use by the business. Licenses, support contracts, warranties, and necessary upgrades also should be documented. Software applications that are no longer supported by the vendor or creator need to be factored into the cost of the merger. Knowing the landscape of the business software and planning for changes during due diligence can save significant amounts of time and money during the execution phase.

Paper Dependent Processes

Many businesses still use paper. Make sure you understand which processes are dependent on paper, how its stored, whether it needs to be converted to electronic format and the like.

Paper can generate storage, security, and accessibility issues for the acquiring business.

Integrating paper processes with electronic processes of the acquiring business can add time, expense, and potential errors, as well as require additional equipment. Investigate this liability up front to appropriately plan for it during integration.

Duplication of Data

Almost all businesses have databases to hold corporate, product, or customer data. Careful examination of the database architecture yields important facts regarding duplicate data that will impact future integrations.  Duplicate data leads to misreporting, inefficiencies, and security risks. It’s not a deal-killer but does need to be examined and understood to determine its ongoing need, security risk, and cost impact to the merger.

Custom Software

Custom software can be a competitive advantage, and help make a target attractive. However, custom software can also hide all kinds of scary things. On the outside things may look shiny and new, but on the inside there may be loads of technical debt.

During due diligence, consider the software’s architecture, dependencies, and implementation. Look at the quality of the code and what tools and languages were used. All these factors impact the cost of the business and its ability to grow and integrate in the future.

General IT, Personal Growth, Software Development, Teams

3 more career limiting habits of software developers

Leave a comment

So you as a software developer didn’t have any of the career-limiting habits from my previous post. Great! Congratulations! You’re totally good and on your way to career growth and unlimited success.

But wait, there’s more.

There are many other habits that can severely mitigate your career growth. So here are three more.

1. Lack of thorough testing

So you have completed a feature and think it’s good to go. Your code is committed. You are feeling good about meeting your deadline. The QA folks are unleashed.

Then it happens. Thirty minutes later a problem is found. Oops.

Many times, I have had developers come into my office, proclaiming that a feature or bug fix was completed, tested and ready do go. Then, when external validation started, something was found within just a few minutes.

Granted we all miss things on occasion. But, if this situation happens too many times in your code, you might be forming the habit of lack of thorough testing.

There are many reasons this occurs. Everything from time pressure to just plain laziness can contribute to this. Sometimes it’s a lack of environmental understanding or unclear requirements. Regardless of the origin, this habit will severely curtail future career opportunities.

You can overcome this by using TDD, BDD or similar methodologies where appropriate. Thinking “testing first” can help you identify and code for those issues up front. Even if your organization doesn’t make formal use of test-driven development methodologies, you should still spend some time thinking through all the ways your code could fail and make sure you handle or document each one. Making that a habit will reduce the chance of an embarrassing situation with your boss or QA just minutes after you pronounce something done.

2. Lack of communication

For an application that is larger than one person can manage, there is a natural migration to particular areas of expertise by the team members.  Alice knows the database interface, Bob knows the CSS and front end, Sarah knows the business logic, Arun knows the device drivers and so on.

We all build silos of information and expertise. This is good and helps us provide value to the organization.

The career limiting aspect occurs when we withhold knowledge (either implicitly or explicitly) that could help other team members. The lack of free flow of information across developers reduces productivity, increases the odds that defects are found late and reduces overall department effectiveness.

If you become known as the person who “knew that last week” but didn’t bother to share with the team, you will become a pariah. The team members who could have benefited from that information will grow to resent you and begin to exclude you, exacerbating the problem of team effectiveness.

It’s a good habit to err on the side of too much communication as opposed to not enough. In the end, you will make the team more productive and be seen as a better team player and better example. It’s a karma-enhancing habit if you believe in karma. 🙂

3. Being a “One trick Pony“

Software tools and technology move at a rapid pace. The hot technical tools and trends of a few years ago become the archeological artifacts of tomorrow.

Back in my high school days, I was pretty good at BASIC.

Guess what. Nobody cares.

If I still relied exclusively on my ability to do BASIC for employment, if I had made it my ‘one trick’, I would have starved long ago.

I moved on to other more mainstream technologies over time such as FORTRAN, C, Perl, Python, PHP and the like.

If you, as a developer, acquire the reputation of being able to only do one thing, it will, over time, severely limit your opportunities.

Think about how technology has changed in just the last 10 years, then extrapolate that out over the next 20 or 30 years. We all better be embracing change. In the future, the most important skill could be the ability to learn new things.

Over a 40 or 50 year, career time span it is imperative to stay relevant. The saying goes “Adapt or Die”.

If you become a ‘one trick pony’ you will be limited in the opportunities that are available to you.

Conclusion

Hopefully, none of these describe you. However, if you have any of these tendencies, now is the time to change your habits so you can reap the future benefits.

 

 

 

 

Development, Personal Growth, Software Development

3 career limiting habits of software developers

Leave a comment

Are you a software developer? Has your career flat-lined? Are you relegated to the back of the pack when it comes to assignments? Are you picked last when it comes to new projects? Have other developers stopped coming by and asking your advice? Has your manager stopped concurring with you for future work planning?

If you answered any of those questions with ‘yes’, then read on.

You may have developed some career-limiting habits without knowing about it.

1. Over promising – under delivering

Estimating effort in a software project is problematic at best and complete fantasy at worst. Some methodologies try to mitigate this, such as agile. But there are still times when a critical fix or change has to be delivered in a bound timeframe. In that case, when the manager needs an estimate, that estimate also encapsulates an implied promise, even though it is called an ‘estimate’.

As developers mature in their craft and environment, the accuracy of estimates generally improves.  However, some developers habitually underestimate how long it will take them to implement a given fix or change.

I have worked with team members who, when asked how long a particular ticket would take to resolve, would say with certainty that it could be done in 4 hours. Then, 2 days, later I am in their office asking why that 4-hour change is still not complete.

When you, as a developer (or as a manager for that matter), miss the estimation mark regularly, you are falling into the habit of “over promising – under delivering”. It could be that you simply ‘shoot from the hip’ and make estimates without really considering needs to be done. It could also be that habitually bad estimates are a sign you have a fundamental lack of understanding about the project, tools or environment. Either case is bad and will erode your credibility and the perception your team members have of you.

If you struggle with small change estimate accuracy, start doing some light weight tracking in a notebook or spreadsheet (if you don’t have a tool that does it for you) for those types of estimates. Use the data you collect to give you better insight as to how accurate you really are.  Once you have a few data points, you can start comparing estimated to actual delivery time. Try to answer the “why did I think it would only take that long” questions. Then use what you discover to adjust your future estimates.

2. “My way or the highway”

Experienced developers have standard ways of architecting and implementing software. This shows itself in the way they organize code, name elements, test or use language idiom among other things.  These are all good and are what make an experienced developer deliver quickly with higher quality in most cases.

I have seen cases in my experience where a ‘my way or the highway’ developer will go into an existing code body and completely violate the architecture and coding standards to implement a feature because it’s not their way.

The career limiting aspect comes in when that developer will ONLY do projects that way. Developers like this only function well in their little worlds. Since most companies have projects that need to be maintained (that you didn’t write), you will always end up writing code outside of ‘your way’. This behavior frustrates the team, confuses future maintainers, creates contention and generally adds to the chaos with little to no actual benefit to the project itself.

An important capability for any developer, regardless of experience level, is a certain level of adaptability. It will serve you, your teammates  and the company well.

3. Tool worship

The modern software development environment has a wide array of excellent tools to make work go faster, and at higher quality. The capabilities of today’s IDE’s (integrated development environment),  compilers, languages, editors, debuggers,  frameworks and DEVOPS tools are must have for any professional developer.

Tools are a necessary force multiplier in our industry. Mastery of a tool set for your environment is prudent and a productivity enhancer. I once had a developer on my team who was an Emacs wizard. It was a real show to watch him edit and refactor code with Emacs because he was so adroit with its interface and shortcuts. However, when you have that level of mastery you tend to want to use that tool for everything. You have heard that old saying: “When all you have is a hammer, everything looks like a nail”.

The problem is when we get so used to one thing and stick with it to the detriment of learning new ways and methods. When we stick with only one tool, regardless of the circumstance, we artificially limit our ability to solve problems with more advanced or idiomatic ways with other tools. And that is the career limiting aspect of tool worship. The software tools at our disposal today are evolving at a rapid pace. And by sticking with the tools you are comfortable with you forgo the personal career growth that comes with learning new tools and the commensurate skills.

Would you trust a car mechanic who tried to solve every car repair with just a wrench or just a screwdriver? Of course not. There are many repairs that need way different tools. Neither should you be a developer that only has mastery of one tool.

Conclusion

A little introspection on a regular basis, and some heart to heart discussions with those who know you best, can illuminate these or other career-limiting habits you have picked up. Knowledge is the first step towards change and improvement.

Development, Product Management, Software Development, Teams

One simple method to improve the design of your next software app

Leave a comment

The late Stephen Covey, in his seminal book “7 habits of Highly effective people“, wrote that one of the 7 habits is: “Seek first to understand, then be understood”.

An effective way to “seek first to understand” and  communicate with someone is to put yourself mentally “in their shoes”. This is the essence of the habit Stephen Covey introduced in his book.

In High School debate, participants prepare to argue both sides of a presented issue. This means a debater has to thoroughly research, understand and prepare cogent arguments for both the negative and affirmative sides of the issue.  The debater has to put themselves in the shoes of both a supporter and detractor of the issue. The best debaters do this well.

This same metal exercise can also improve your next software application.

Key Mental Exercise

By changing mental viewpoints and analyzing the software project from the new point of view, you can become aware of new issues to solve or new opportunities and features. You can do this regardless of your role on the team.

This exercise helps prepare you for the client meeting, that big design review or the next sprint planning session. It can help you work more closely with the product owner and improve your design and plan.

If you are one of the general roles of a project team, forcing yourself to mentally assume the viewpoint of the other roles in the software project will improve communication, understanding, planning, and results.

Forcing yourself to assume the viewpoint of other roles in a software project improves results. Click To Tweet

7 viewpoints of a software project team

Here are seven viewpoints you can use in your mental exercise:

Designer

The designer creates the look and feel, screen flow and color scheme and page layouts.

Designers are concerned with creating a compelling user experience in a style that complements the genre and use of the application. Style, simplicity, cognitive load, and utility are  key concerns the designer has.

If you are not the designer, you can consider methods to express style, or improve the usability of the app.  Realize there are many opinions that influence the aspects and implementations of design. Many times there is no one right answer. The designer has to arbitrate these, sometimes conflicting, opinions.

Developer (coder)

The developer is the person (or team) actually doing the coding of the application.

The coder has to worry about the execution environment, standards, tools, compatibility across consumption devices, security, language implementation, performance and 3rd party services, code libraries and API’s that will be used.

To put yourself in the shoes of the developer, consider the job of a translator, translating one language to another. There is a lot of work  and knowledge that goes into translating a language. Nuances such as tense, idiom, gender and the like add complexity as well. That’s essentially what a developer does, translating the requirements and desires of the team into software, but also with a lot of other constraints.  Many of the constraints coming from the environment and devices that have to run the app.

Project Manager

The project manager is responsible for schedule and resources.

Their big concerns are resource utilization, schedule, milestones, reporting, test results and barriers to completing the tasks. And, if the project manager doesn’t have direct reporting control of the resources, their job is much more difficult.

To envision their world, think about being the director of an elementary school orchestra. They attempt to get all the band members set up with their instruments and music, on key, and on tempo so that what the orchestra plays will actually resemble music.

Owner

This is the person who is funding the development. The business owner or VP who is sticking their neck out (and budget) to get the project done.

To think from the owner’s frame of reference, consider making a large purchase with your own money. Writing a big check out of your own account always gives you pause. It motivates you to thoroughly investigate the value of the purchase, the terms, guarantees and warranties and lifetime costs and service. You don’t write big checks out of your own account without sufficient reassurance that the purchase is a good one. Thinking about the owners situation in this manner helps you better evaluate the value proposition, return, and on-going or hidden costs. All of which are key concerns for the owner.

Customer

The people who actually pull out their credit card and pay for and use the app you are creating.

They will have lots of needs and questions. Why should they buy? How will they realize value? What will their pain points be? How will they consume the app?

All of these and may more questions will have to be answered in order to produce a product that is valuable and has utility for the customer.

Competitor

Consider those companies with products already in or directly adjunct and selling to the market space you will be in.

What are the pain points of the customers of your competitors? What is the competitors unique value proposition versus that of the app you are building? Why would customers potentially buy from your competitor and not you?

Answering these questions will provide greater clarity about the market position, value proposition and relationship to existing competitor offerings.

Maintainer (another developer)

The maintainer is the poor souls who come after the initial release to clean up after the parade and maintain the app and system that was created.

What documentation will they need? How can you structure the app code to improve maintainability?

The maintainer will be the person fixing bugs, adding features and making other needed additions and improvements. Making their life easier through well architected and written code, template based screen layouts, comments and a software spec will speed maintenance activities lowering long-term cost of ownership.

Summary

If you spend a little time, thinking about your project from the viewpoints of the various roles, you will be a better team member, facilitate better communication among the team and make the project go smoother and improve the results.

Work on assuming the viewpoint of others to more deeply think about your application, improve your results and reap the rewards. And, who knows, you might make it a habit.

Development, Personal Growth, Software Development

5 reasons software development managers should still code

Leave a comment

Cue the Psycho music. Throw in a Wilhelm scream. Run for your lives!!!  To some alpha developers, the mere thought of a software development manager coding is worse than 12 hours of fingernails on a chalkboard. And scarier than a night in the Bates Motel.

Yeah, I get that. But wait.

There are some valid, and practical reasons for a software development manager to also take a few story points  in a sprint now and then. Here are five.

1. Keeps your skills sharp

Today’s development languages, technologies, tools, and environments evolve with ever quickening pace.

The experience you had as a coder 10 years ago is aging faster than the milk left out on the counter last night.

Taking a few story points now and then forces to you learn and keep up with tech, staying relevant in your field and your own product and environment. It also allows you to communicate with better understanding and at a deeper level with your development team.

2. Refreshes your familiarity with  development environment

But doing a development turn now and then you keep fresh in your mind the nuances of your companies particular development environment. And the pain or bliss it causes your team.

This knowledge can also improve your on-boarding process and make you more relevant in discussions when it comes time to migrate to new elements in your environment.

3. Deepens your product knowledge

By actually doing development on the products you manage, you will be far more knowledgable and effective in your communication to customers and superiors. You will understand the context of defects and issues that come up more thoroughly. You will be able to communicate with your team at a higher bandwidth during feature design or sprint planning.

4. Coverage for vacation, sickness, and emergencies

Sometimes you will find yourself in a pinch.

Your key developer is out, camping in the remotest parts of the Colorado mountains and completely off the grid for 2 weeks. The other guys are slammed and a defect found in his code needs to be addressed and pushed to production in 2 days.

If you have been keeping your skills sharp and doing your turns, you can step in and cover this situation in most cases. I know I have.

5. Respect of your team

If you can still take a ticket or two now and then, you will also silently earn greater respect from your team. They will believe you are in the foxhole with them. Your questions to them will be more on point and from an orientation of better understanding.

Conclusion

There is an influence from the professional management ranks that anyone with the requisite management training and skills can manage software development without the pre-requisite of coding experience. I have worked with PM’s who were good enough to pull that off. However, the PM’s who had actual development chops were far more effective in my experience.

So scare your team to death and sign up for a few story points in the next sprint.  In the long run, I believe you will be a more effective software development manager for it.