Uncategorized – Software Development Manager

Software Engineering Manager Certification

Posted on November 9, 2020November 17, 2020 by Steve Padraig in Uncategorized

We have developed Software Engineering and Software Engineering Management certifications that are not technical but informative of your strategy, process, policies, standards, opinions, and transferable skills that cover 90% of software engineering and software engineering management. They can be applied generically across all vendors or programming languages that cover the remaining 10%.

Take our Software Development Management course if you want to study beforehand and achieve Software Engineering Manager – Level 1. If you are already experienced jump in and take one of the exams now.

We have four certifications to choose from:

Experience v education v international experience and education

Posted on August 30, 2020August 31, 2020 by Steve Padraig in Uncategorized

I’ve been a software engineering manager/director in over 30 countries – covering all continents. With vast amounts of software engineering professionals in demand world wide it is important to recognize, value, and treat equally skills and experience wherever it comes from – or lose them.

How do I evaluate candidates?

Experience

Gradually over time a candidate’s experience is more relevant than a distant education. My first scan of the resume as software engineering manager is recognizing the relevance of experience in a candidate’s resume to the job posted – or their ability to adapt. This is made easier with a well worded job description that reduces resumes received.

There are many routes into software engineering, not just universities. I first compare a candidates experience to the posted job using:

Size and complexity of projects
Project or product types
Business types
Technologies and methodologies

There are no total years of experience, nor have we got to education. It is only do they show experience that they can do the job – regardless of place-of-origin. If they can an interview strategy is devised to see if they can. The focus is looking for the similarities for the posted job, and not differences in national culture or where educated. In an inclusive and diverse society differences in culture are tolerated so its not an issue.

There are many employers that will have rejected candidates on education alone – some even stricter on country educated. In that case not all remaining candidates will have the experience – but many that do have been excluded. Putting experience first creates a list of only potential candidates.

Expert software engineering managers putting experience first will not have the wool pulled over their eyes – but HR selecting on education first already have.

Education

My second scan of the resume pile that now only contains experienced or able candidates is looking at education. If the candidate has the experience they claim they will be well educated – so I place far less importance on education than experience. I place more emphasis on education when recruiting newcomers to software engineering.

Vast majority of employers around the world accept university degree’s, college diploma’s, and high-school education on face-value regardless of place of origin especially when the candidate has actual experience. Interviewing a candidate will test the quality of that education – but it needs an experienced software engineering manager to interview.

What about other post-secondary education or if you have doubts about university degree’s, college diploma’s, and high-school education? Whilst walking with the candidate from reception to the interview room ask these 3 questions.

Was the education fulltime or part-time?
how many hours, over how many years?
What were some of the items on the syllabus? You can even prompt a few.

You now have enough information to compare their education to something you are familiar. If you want it earlier or more information use google or phone the candidate. There should be no need for candidates to pay $1,000’s to have education assessed for local compatibility, attend bridging courses, or re-take entire degrees. Software engineering is an occupation that is the master of standardisation, and computers and software are the same in all countries. Interviewing a candidate about software engineering is sufficient to quantify their education and experience.

That’s how easy it is. The real work is with experience and the software engineering teams ability to interview and assess experience through discussion with the candidate.

Attracting International Skills

London UK where I was based has 8 million of which 60% are British and 40% foreign. Most European capitals have similar demographics – and I regularly travelled to all 27 of them from my base. The ratio of leaders I reported to and the teams I worked with in European capitals as a consultant was fairly consistent with the ratio of citizen and legal immigrants. They are also very accepting of foreign education and experience and attract talent from all over the world. Other places I have worked only allow immigrants at entry level, some even stricter after getting a local post-secondary education. It restricts immigration to those with little choice of anywhere else to go. If you want the best you have to treat them the best.

Conclusion

In all my years not one candidate has been so dishonest about their experience and education that I would have to fire them immediately. An employer with doubts can offer a probationary period, and a candidate knows that if they were dishonest, they will get fired with or without a probationary period. We are software engineers not doctors, and can take precautions.

Photo by Anthony Shkraba from Pexels

Internationally experienced software engineers and managers add value

Posted on August 26, 2020August 26, 2020 by Steve Padraig in People, Software Development Manager, Uncategorized

They gain exposure to projects they could not have in their home countries.

When I was in the UK, we had many Australians, New Zealanders, South Africans, and many others work on such projects. With small projects or smaller populations such as Australia and New Zealand, it is important to have jack-of-all-trades, that is people who are multi-skilled. That doesn’t mean they were not also highly specialised. Likewise, larger projects and larger populations such as the UK, Germany, France, US, and China can afford more specialised people. We gave exposure to large projects they didn’t often have at home – and they were inspiring us to be more multi-skilled. As a result, the international market opened up with my new multi-skilled ability.

There are large and complex projects, and small and simple. There are a variety of project and product types. It is rare if anyone can find such experience in one location. Working with or being an international software engineer has great benefits for knowledge transfer.

They also have a wider exposure to a variety of tools, processes, and technologies and at different stages of maturity.

Software engineers without international experience often focus on knowing software engineering trends for their country very well but less on what is happening globally – they may re-invent the wheel or not be knowledgeable about the latest worldwide trends. International software engineers can bring new ideas to the table with knowledge & capability to compare & contrast from experience in variety of countries. It makes them more efficient and ultimately more strategic with their time as they pick from the best tools, process, and technology.

Each country is at a different stage of its growth and cycle. Legacy software in developed countries is often greenfield projects in developing countries. Some countries are moving forwards with large legislation changes such as in financial trading, import and export, or taxation. Eventually each country will at some point go through the same process and need these internationally experienced software engineers to save re-inventing the wheel.

They have learnt more about team building and leadership working with a variety and mix of cultures.

Team structure and reporting line can be very different between countries. Across UK and Europe, the structure is often very flat

Board
IT Director
Software Engineering Manager
Software Engineer.

In Canada it can be

Board
VP/CIO
AVP Software Engineering
Director of Software Engineering
Assistant Director
Software Engineering Manager
Software Engineer.

Even the well-known methodologies of agile and waterfall are modified to match local culture. Some cultures prefer micro-managing and others more trusting – the international software engineer quickly adapts and knows when local culture trumps any favouritism to waterfall or agile.

Places such as UK, Europe, Asia, and the US have no problems with a foreigner in a leadership position allowing the teams and leaders to flourish without borders. A few do not allow that and teams stay stuck in their old ways – especially in a culture that micromanages more than they trust. I have worked as a software engineer or software engineering manager in over 30 countries and it is the countries and their cultures that have inclusion and diversity that permits foreigners in leadership that flourish the most. There is one “developed” country that will not even permit foreigners to call themselves a software engineer or teacher of software engineering, unless they were educated in that country, nor will they permit them beyond role of developer or computer programmer. It is no wonder that country had many examples of old tools, processes, and technology and struggled to fill them. This reluctance to be inclusive led to sales and administration staff being “drafted” into IT roles

Conclusion

Overcoming challenges when team members have different ideas, opinion, and methodology on a solution is one of the most important skills for a software engineer or manager. Internationally experienced can do so when cultural differences exist too. They know the right questions to ask, and when to listen. They too have learnt to quickly adapt to other cultures and working styles. Software engineers and managers with international experience have proven they are courageous enough to step outside their comfort zone and quick to learn on their feet. Including them in homegrown teams is a must to transfer that knowledge. Teams that don’t struggle when they have to work with overseas teams – or continue in ways that the rest of the world no longer uses.

Photo by Porapak Apichodilok from Pexels

Version Control – Branching, merging, tagging strategies and best practice

Posted on July 30, 2020August 3, 2020 by Steve Padraig in Uncategorized

Version Control Features

Version Control is the management of changes (versions) to documents, files, and software.

Trunk/Head/also called the first branch – is the main body of source code. Branches begin as a copy of the first or subsequent branches – and are for adding new features or experimentation without affecting the branch they stem from. Eventually they are merged to the original branch and cease to be of use. Merging is integrating the changes of a branch – normally back to the original branch. Tagging/labelling – is a marker on a branch so we can retrieve the source code as it existed at that point in time.

If we are not careful we can create a bigger problem than the solution version control was intended for.

Strategies for Version Control

1. Simple Strategy

First Branch is used for development, and the support branch is used to support the production version

New software developed on the first branch and when ready for release we tag the first branch to mark it. We make a copy of the first branch named “Support Branch” in this example. New development can continue on the first branch. The release is made to the customer from the first branch.
A customer detects a problem and it is fixed on the support branch – not containing on-going development that is on the first branch. The release is made to the customer from the support branch this time. The support branch is tagged to mark the point of the release – so we can rollback if need be.
When we release from the first branch again we want to include the fix from the support branch – so we copy/merge that change to the first branch
Now when we make a release from the first branch it will include all changes made on the support branch.

2. Release Branch Strategy

Release Branch Strategy slightly extends the simple strategy – First branch is for development, the release branch supports the test environment rather than the production environment as in the simple strategy.

Some organizations require parallel testing and want fixes in the test environment to be more immediate.

Release Branch Strategy supports on-going development, and both test and production environments that have different versions of the software.

New software developed on the first branch and when ready for release we tag the first branch to mark it. We make a copy of the first branch named “Release Branch” in this example. New development can continue on the first branch. The release is made to the test team from the first branch.
A tester detects a problem and it is fixed on the release branch – not containing on-going development that is on the first branch. The release is made to the test team, from the release branch this time. The release branch is tagged to mark the point of the release – so we can rollback if need be. It is possible that a fix is identified in the first branch in which case it can be fixed in either first or release branch and then merged to the other.
When we release from the first branch again, we want to include the fix from the release branch – so we copy/merge that change to the first branch
Now when we make a release from the first branch to the test team it will include all changes made on the support branch.

When release branch is deemed ready for release to the customer, we release from the release branch and tag it at the point of release.

3. Feature Branch Strategy

The feature branch strategy has no upper limit on the number of branches – there is one branch for each feature. It separates teams and features onto their own branch. When the feature branch is finished it is merged into the first branch and the feature branch deleted.

First branch is only for accepting merges from feature branches, it is not developed on. In this example feature branches A, B, and C are all created from the first branch at different times in that order.
In this example feature branch B is first to complete and is merged to the first branch and tagged. During this merge it does not have to contend with changes made on feature branch A
Now feature branch A is completed and merged to the first branch. Not only does it have to deal with conflicts between the first branch and feature branch A but it also has to deal with conflicts caused by the merge of feature branch B. Feature branch C has yet to be merged.

Best Practice

Use the rules of the version control software you have implemented – and choose wisely which one you use.
Keep branches to the minimum
Use change evaluation and feature switches to remove the requirements for branches, and predict when a merge can be difficult and plan around it
Only use the Feature Branch Strategy when there are large numbers of high-risk changes – or if the feature adds new objects with little modification to existing objects. Use Release Branch Strategy for other development – better still use change evaluation and feature switches to avoid a feature branch
Merge regularly. The greater the change and the longer the time results in the greater differences between branches – and even if it is still possible to merge .

Team Building and Recruitment Strategy

Posted on July 21, 2020July 22, 2020 by Steve Padraig in People, Software Development Manager, Uncategorized

Team building and recruitment for software engineers is part of the Software Development Managers job. These are some of the “non-techie” and “soft skills” I look for when building a team. Most cannot be identified by an ATS.

A carefully constructed and updated job description written by a Software Development Manager or Software Engineer for a specific job can target specific candidates – unlike some of todays “capture whole department” JD’s written by non-techies. We never had a problem before reducing applicant amount using accurate JD’s, and filtering them by eye. I would say we had a better outcome as great candidates always get to the front of the line. It is imperative that the Software Development Manager and their team(s) are involved at all stages of recruitment.

Project Size and Complexity

For small projects it is important to have jack-of-all-trades, that is people who are multi-skilled but for larger projects specialized people in each area become more and more important.

We also need to consider the size and complexity of the project, and the time it will most likely take to complete. There will be peaks and troughs in effort required and dependencies between tasks. To fill these peaks and troughs it would be foolish and expensive to recruit more permanent staff – unless they can be re-allocated from elsewhere in the organization. If the resources are from the existing resource pool then there are no real risks but should you employ someone specifically for the project you need to consider local employment rights legislation.

Qualified or unqualified, Academic or Experienced?

Qualification is used by HR and ATS’s and filters out experienced candidates. A Software Development Manager can see real experience with or without qualification in a resume or interview. I also hold the view that qualification alone is not useful unless we have real experiences and there are people with experience but no qualification.

Academics can pass tests but have little if any practical experience to solve real life problems, whereas, experienced people have real-life practical experience and may find tests suited to academics harder – but given a real-world test will flourish.

We need experience and ability, but also responsibility to give newcomers a chance, therefore, we must balance the team, and we may require two interview strategies to do so.

Domain Specific or Global?

Domain specific software engineers focus on knowing software engineering for one industry very well. Global Software Engineers bring new ideas to the table. If we stuck with just domain specific software engineers, we are likely to get stuck in our ways – and create our own skills crisis. Again, we can balance the team with both. If we recruit from one domain we lose lots of opportunity to grow.

Pragmatic, Evangelist, or Zealot

With doubt pragmatic’s as they are guided by practical considerations than by ideals of any tool, process, or technology. They will know the time when to implement a quick or elegant and robust solution, and most likely to see a balance between practicality and perfection. Evangelist can be an excellent choice for a change program.

Skeptics or Optimists

Optimists assume their code will never fail and reduce testing to match, whereas, Skeptics will test far more thoroughly.

Asks questions?

Great Software Engineers question and constructively criticize a plan if it doesn’t make sense. Others do word for word whatever you say without question. We need those who come forward – but we should accept responsibility as a manager to ensure we also give opportunity for them to come forward and not reject them.

Can take the rough with the smooth

Many software engineers love to write new code – but few loves to debug. Fewer will want to debug someone else’s code. Great software engineers even if not enjoying the task will dive in and resolve the bug – even if it wasn’t theirs.

After much time solving a problem with a particular tool, process, or technology evidence arises showing others are or even were better. A great software engineer knows when to press the rest button and admit when being wrong

Many are fans of waterfall or agile but not both but a time may arise when a short project using the other came along. Great Software Engineers will get on with it

Many like to work on the latest technology but there are times when we have to maintain legacy software. Again, great Software Engineers will just do it.

Conclusion

It is very easy to exclude and create a skills crisis where none existed by being to specific with qualifications and domain requirements. We can also create problems in the team spirit if we recruit non-team players such as zealots or those that cannot take the rough with the smooth. We need also to look at where a candidate and employer can collaborate with the candidate bringing new ideas to the table, and the employer offering the candidate a chance of new experiences.

There is a lot more to team building and recruitment that an ATS can cope with. Only a Software Development Manager or Software Engineer has ability to extract this information with discussion.

Optimists or Skeptics

Posted on July 8, 2020July 9, 2020 by Steve Padraig in Uncategorized

I got a question from one of my students taking my Software Engineering Management course about root cause analysis. They had a Software Engineering team that always produced buggy software. It had little fault tolerance and where it failed it didn’t do so gracefully. Most of it is caught by testers and returned but this is an inefficient loop. No matter how much they tried they could not get the software engineers to write less buggy code.

We eliminated tools, process, and technology and ended up (as often as I do) that the root cause is most likley in the recruitment processs. Job descriptions and pre-screening by HR had a bias for optimists. Anyone with an ounce of skepticism rejected.

I always advocate a balance between optimists and skeptics in any Software Engineering Team:

Optimists assume their code will never fail or some exceptions may never occur. They reduce testing as a result and always believe they have done enough.
Skeptics even with code that appears to work well assume it will not. They will capture all known exceptions and ensure whenever there is failure it is graceful. They will test extensively.

I think it is imperative that the Software Engineering Manager is involved in all stages of recruitment for their team.

The (W)hole Story

Posted on December 6, 2019July 9, 2020 by Steve Padraig in Uncategorized

A software team has dug itself into a big hole. As Software Engineering Leader I’ll throw new tools and materials of your choice into the hole. What will you do with the tools and materials?

build table and chairs to make the hole more comfortable
build a ladder and climb out of the hole

It’s a question I use to lead Software Engineers to make the correct conclusion unavoidable, and they arrive at that conclusion themselves. If I told them what to do there would be less buy in than trusting them to make their own decision and having complete buy in. It is difficult as a leader if you believe the wrong option is chosen but if you give the team breathing space to make a mistake they will learn. Listen more and talk less to show you value their expertise and that maybe you will learn that they chose the right option. It’s more important to value the team’s opinion and expertise and grow together than say “I told you so.”

It’s a big ask to step back but easier when a leader has non-negotiable standards expected of software engineers that control the quality of the final output such as standards for – coding, object-orientation, testing, security, architecture etc.

It’s just one way I can help organisations with Software Development, Software Engineering, and the SDLC.

Software engineers, programmers, developers, and data scientists – are they all the same?

Posted on November 22, 2019July 8, 2020 by Steve Padraig in People, Software Development Manager, Uncategorized

Today we have many titles for what many believe is essentially one role. They have evolved over the years into very specific roles of their own.

Programmer/Developer – read and write code which is specified for them.
Analyst & Programmer/Developer – programmer/developer + the ability to specify, design, and document a software component.
Data Scientist – developing methods of creating, updating, reading, deleting and analyzing data. NB: Data Analysts interpret data
Software Engineer – Analyst & Programmer/Developer + Data Scientist + ability to specify, design, and document a software system of multiple and reusable components. Better ability to be self-managing and high-performing team member.The engineer sees the wider picture and communicates with other team members near and far to build a system to a specification that both during and after construction does not impede other engineers, developers, and programmers. An engineer is more object-orientated.

Pre-Y2K it would not be unusual for a single software engineer to perform all four tasks but now nearing 2020 the art of software-engineering is being sub-divided further still with fewer practicing software engineers left. It should be stressed though that a software engineer is not a “jack of all trades and master of none” as they are quite capable of being a master of all software engineering.

Is this sub-division a good thing or a bad thing? That all depends on the projects you aspire to be on and how transferable you wish your skills to be.