Category Archives: Software Development

4 key Data tools to advance your IT or software and data career

Whether you are a system administrator or you write real time avionics control software for military jet fighters there are some common tools that will enable you to do your job better and handle many scenarios with ease.

They may not be part of your standard day to day tool chain but they can enhance your corporate value and situational agility.

1. Excel

No matter where you go Microsoft Excel seems to be there (or Google’s Sheets).

Excel is a swiss army knife of data manipulation, analysis, computation and modeling. There are a lot of use cases for software and IT staff where excel can be your goto tool.

I use Excel regularly to

  • Clean and normalize data
  • Rearrange data to suite some new need or analysis.
  • Summarize data quickly with Pivot Tables.
  • generate executable code for putting into other programs.
  • Automate tasks (yeah VBA ….)
  • Advanced analysis and optimizations
  • Convert data formats
  • Modeling
  • and more…

The filtering in the data view or (tables) is hard to beat for super fast analysis and getting quick answers. And the newer versions support PowerQuery/PowerPivot which gets you beyond that annoying 1 million row limit!

Technical employees would do well to maximize their understanding of this very powerful tool (and its web kin).

2. SQL (Structured Query Language)

If French is the language of love, then the language of data bases is SQL.

SQL is how you ask a database questions. In the simplest example you can select data from the table you are interested in.

SQL is harder to learn for beginners but is very powerful. With SQL you can not only select data you want from a database but you can do complex computations, transformations, data summarizations and ranking, data partitioning and joining together of data from separate tables. 

There are several very popular powerful databases that you can download for free to learn such as MySQL or Postgres

Knowing basic SQL WILL enhance your value to an organization and give you new opportunities for advancement and assignments.

3. Python and the Python Data stack

If SQL were a bulldozer then Python and the Python Data stack is a whole fleet of earth moving construction equipment.

Python is a very approachable yet extremely powerful programming language for those new to programming and is easy to learn. Python has tons of built in capability and loads of add on libraries that make the most sophisticated analysis and data mining doable.

Python can help you automate the boring stuff and make tedious data work quick and easy. And python runs on all the popular platforms like Windows, MacOS and Linux to name a few.

I use Python in many ways to automate tasks, connect disparate data sources, perform analysis, build synthetic data sets, serve web pages, send emails,   process tons of data and generally enhance my life.  I also use python do automatically generate Excel spreadsheets too.

Adding Python to your personal skill repertoire is a huge value add for your technical skills.

4. PowerBI

Microsoft PowerBI has quickly become one of the most powerful and popular Business Intelligence packages. If you need to connect to a variety of data sets and perform analysis and publish dashboards of results PowerBI is your tool.

PowerBI is Excel overdosing on steroids.

With powerful data connection tools, data modeling and programming tools and a bevy of visual presentation widgets to make impactful analytic dashboards PowerBI is a data powerhouse.

Businesses are embracing PowerBI for its power, cost and flexibility to allow data connection, gathering, computation, transformation, presentation and communication to staff, employees and customers.

Conclusion

All four of these tools are widely available and used, not expensive, and very powerful. They will definitely give your skill set a boost and your productivity too!

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

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.

 

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

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.

 

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

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.

3 more career limiting habits of software developers

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.

 

 

 

 

3 career limiting habits of software developers

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.

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

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.

5 reasons software development managers should still code

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.

 

Hey software developers 6 simple ways to help the developer that will clean up after your parade

I never write bad code. My code is always readable, perfectly modular, standard following, understandable, completely commented and idiomatic with 100% code coverage unit tests.

Ok. You can stop laughing now. Really, stop laughing.

As software folks, we will always bias that our code  easier to understand than that written by someone else.

Of course it is. You wrote it.

We get used to our own style, habits and ways of thinking about software implementation. It’s natural.

However, when it’s crunch time and the the deadline is now or our motivation is less than stellar, we have all written code, that, upon later reflection, is not much better than rotten barnyard material. Sometimes we write code that way during times of less stress and pressure too.

When you write code like that for a business, realize that someone will come after you. And the person who comes after you will have to fix bugs, add features, migrate to new environments and any other number of interactions with your code.

What will that person find?

If you want to pay it forward as a developer (and I am requesting you do), here are six simple ways to be kind to those who will work on your code after you are long gone.

0. Document block your files, classes, and methods

State your assumptions, purposes, reasons, pre-conditions, dependencies. Tell those coming after you what will help them understand not just what you did but why you did it.

Sometimes it can seem redundant (especially if your code is as good as mine) but a good doc block can clarify a class’ purpose or the reason a method is implemented the way it is. Plus a good doc block can be the high level overview that makes reading and understanding the actual code go much faster.

Doc blocks are a super help to the software archeologists that come after you and try to add features or refactor your code for some other reason.

1. Comment your code inline

Really? Are you kidding me?

I am astounded that with all the “software education” and common best practices we have access to, professional (?) developers still neglect to add relevant comments to their code.

I recently went through a file that was several thousand lines (yeah, I know) and there were no comments. We were trying to re-factor a bit of old code to perform correctly in PHP7. In a particularly obfuscated section of code I found myself asking “why did you do that?”, over and over again.

A simple line or 2 of comment in a method or variable definition can  prevent the person coming after looking at the commit log and cursing your name and yelling “What were you thinking?” And, if by chance, you happen to come after yourself a year or two later, a comment will help you remember why you set:

$Contibulator_Fudge_Factor_Ratio = 4.26;

2. Mind the coding style

You will annoy those who follow you by randomly changing coding styles. Tabs or Spaces? Braces on the line or under the line? Camel case or underscore separated names? Whatever you choose, do it the same way.

Consistency means those after you only have to figure out something once. This is especially true if you are adding code to a system that you didn’t write either.

3. Maintain architectural intent

When you code, have consistency in your implementation. There are few things more disorienting than trying to figure out why a previous developer had 3 ways of doing things.

When you need to talk to the database, do it the same way each time.

If you are coding an MVC app, be consistent on your division of work. If you use a template in one view, use them in all your views. If you start with ‘thin’ controllers, keep it going.

If the data representation is JSON, use it consistently. Don’t throw in some XML here or there just to mix it up.

If you have a ‘js’ folder with your site javascript files, don’t all of a sudden start creating template files with 400 lines of embedded javascript (without a comment).

Finally, if, for some reason, you have to do something that is a deviation of the architectural direction – add a comment!!!! Tell us why.

Consistency in your implementation will also help speed any future re-factoring efforts that you or some other developer may be tasked with.

4. Communicate with variable names

Variable names like $x, ‘res’, ‘m1’, ‘ary’ and similar communicate nothing to a reader about intent or purpose. Outside of idiomatic usage, say, as a loop counter in a C language for loop (for i=0; i< 10; i++), these types of variable names scattered throughout a code base only serve to obscure and confuse.

If you have a display mode setting string variable don’t call it $dm. Call it $display_mode_setting. If you have a post count variable don’t call it ‘pc’. Call it ‘post_count’. If you have an array of customers that are expiring their trial usage call it $customers_with_trial_expiring_list[].

You get the idea.

Simply use the context of the variable usage to name it accordingly. Think about telling the developer after you something by virtue of the name of the variable. In this manner, any later developer who sees these can more immediately grasp its purpose.

5. Guide with commit comments

So you’re assigned a bug to correct a situation where a NULL file pointer is accessed causing an exception. You realize there were several commits to this file and check the previous commits against that code. You notice that there used to be a NULL check but it was removed in a commit 4 months ago by a developer who is no longer working at your company, and they didn’t put a comment in the commit. Now you are left wondering if that guy a compete moron or was there some other unknown reason the change was made. Maybe it was unintentional but maybe not. Without the comment you have no idea why. You simply soldier on wondering.

This situation can be improved with a simple commit comment.

Something like “Remove the NULL check here, the IO library group will handle it”.  This communicates a whole new level of information regarding the change. It gives you a clue on where else to investigate to make sure your solution is correct and complete and it only takes 15 seconds. Yeah it’s a bit contrived but it illustrates my point.

Good commit logs help those after you unravel the history of the code changes more effectively. Log those commits.

Conclusion

I know, these are coding 101 items. The sum total of time it takes to code this way is only slightly longer that without it. Even so, it is disappointing to see how often these simple actions are ignored.

And, as someone with the responsibility to maintain a fair amount of previously developed code, the lack of these 6 things makes me want to pull my hair out. I know you feel that way too.

I like the way Brandon Savage says it in his book “Mastering Object Oriented PHP“. He was admonished by a previous manager to:

“write code as though the developer coming after me would be a psychotic murderous maniac who had my address”

Humorous, yes. But it contains a great truth about helping those who come after you.

Let’s face it, without a Vulcan mind meld, it is impossible to be on the same wavelength as the original author of code you might be  working on. But with a small amount of effort you can lessen the frustration those who follow after you and even become a code hero in their eyes. And who knows, the frustration level you lessen may be your own.

 

 

 

 

 

 

5 ways a small business can protect itself from losing the software developer

For a small business with high dependence on customized or proprietary software and online tools, a good software developer can be a lifeline to better efficiency, growing revenue and increased profit.

But what happens when that software developer leaves the company?

For some companies this can be a disaster.

What were simple requests before, now become profoundly difficult obstacles. Making basic website updates, adjusting the troublesome customer’s account, or running the custom reports for the CEO now become almost impossible.

It doesn’t have to be like that.

With some basic planning, standards and consistent communication  you, the business owner or executive, can mitigate much of this pain. Here are 5 ways to start.

1. Use source code repositories

Make sure any developer that does work for you is keeping the software files for all projects in a source code repository that you own and control. It’s like a library for the files that make up your delivered software.

The software that is created for your business should be treated like an asset so as to maximize it’s long term value return to the company. A good code repository helps protect that asset.

There are many programs that act as software source code repositories. Systems such as Atlasssian’s BitBucket or Github are popular, loaded with features, inexpensive and conveniently online. You can also download and use local versions of systems such as SVN or Git for the more technically capable.

These systems facilitate modern, flexible source code control with many integration options for other parts of the software development and delivery eco-system.

If your software developer insists on keeping code on their local hard drive, its time to find another software developer. You can’t afford to have your software walking out the door when the resource decides to leave.

2. Use ticketing or issue tracking

A ticketing system or issue tracking system is a tool to document and clearly divide units of requested work when used correctly. To a small business this may seem like a lot of overhead. However, a ticket tracking system is a way to more clearly communicate what needs to be done, who is doing it and track progress over time, and potentially across multiple developers.

Online systems such as Jira, Fogbugz or Trac can be used at a reasonable cost. Also Mashable has a longer list of issue trackers you can use.

A ticketing system is also a way to maintain accountability and communication regarding specific tasks and requests. Many of the systems allow you to pull reports and see how things are going, how a project is progressing and measure quality metrics for your code.

3. Keep systems and software diagrams

Every small business should have a basic diagram (could be paper or electronic) that shows where things are. Items such as key servers, locations, databases, internal tools should be shown along with what relationships there are.

As changes are made and systems are added or migrated, update the diagrams as part of your standard procedures. Review it from time to time to validate its accuracy. Adjust it as needed.

A simple diagram that shows where and how your systems link together can save hours of time in misunderstandings or unclear documentation. It can also make on-boarding of a new software developer or system administrator much easier and faster.

4. Track passwords and access

A developer will need access to systems to update code, release software and make fixes and changes.

The small business should own all the passwords and control of them. Allowing the software developer to be the only one who knows the admin passwords is a recipe for disaster.

In order to track a large number of passwords I recommend using tools such as Lastpass or 1password. These tools allow tracking of passwords and provide online and mobile access for convenience. Alternatively you could store passwords in an encrypted file or disk volume (as long as it is backed up elsewhere) with the operating system you use.

The bottom line is that, as the owner, you need to be able to access these systems when the developer is no longer available for what ever reason. Tracking the passwords yourself helps guarantee that access.

5. Maintain regular communication

This is perhaps the simplest but most neglected area.

Business owners and executives get busy. It’s easy to forego the regular, sustained communication that facilitate shared understanding of a software project. Neglecting this communication will cost you when it comes time to transition to a new developer.

Setup and keep a regular meeting schedule to discuss issues, progress, and review updates. This should be done at least a couple of times per week, or daily if possible. Once you get in the groove, these meetings are usually short.

Many teams who use the Agile methodology have stand-up meetings every day to discuss progress, issues and immediate plans. This quick, consistent communication helps educate you, as the owner of the software, and educate the developer to your expectations and needs and the systems evolve.

Force yourself to meet and talk. Ask questions and get answers without technical jargon and acronym soup. Any developer worth their salt can explain what they are doing, and show examples in terms any businesses person can understand. If they can’t, its time to upgrade.

Summary

The departure of your software developer can bring about loads of pain without proper preparation and planning.  But with preparation you can facilitate smoother transitions between developers and lessen your companies downside risk.