Month: August 2022

Three Tips for Finding and Hiring the Right Team for Your Project Management Or Software/Web Developer Project

Posted on by Josh Freese

project management or softwareweb developer

Whether you are a project manager or a software/web developer, you need to have a clear idea of what you are trying to achieve. Documenting your tasks is an important part of your project, as is monitoring your team’s progress. You also need to have a set of milestones for your project, as well as a clear idea of how long the project will take and what the costs will be.

Create a team for your web development project

Having the right team for your web development project is a crucial component of the process. Not only should the team be experienced and highly skilled, but it should also be able to effectively communicate. Here are three tips for finding and hiring the right team:

Identify the type of website you need to build. This can help you define the scope of the project and guide the negotiation phase.

Determine your budget and timeline for the project. This will help you determine the size of the team you’ll need. Depending on the complexity and length of the project, you may need more or less developers.

Find out what other roles can be included in the team. For example, you might want a QA engineer to test the functionality of the website. You might also need an SEO expert.

Create milestones to help structure your project

Using milestones to structure your project management or software development project is a great way to keep your team on track and focused. They can also help you course-correct a project as needed.

When used correctly, milestones can boost productivity and efficiency. They also can keep costs from spiraling out of control.

A milestone is a point in time and a sign of success in a project. They are also useful because they are a checkpoint to see how far along the project is.

The PMI defines a milestone as “an event, a measure, or a signal, which has a positive impact on the organization.” They are typically defined during the planning phase of the project. They can be added or removed after the project has begun.

Monitor team progress on a granular task-by-task level and on a big-picture level

Having a task board is an essential tool for monitoring team progress. It provides an overview of tasks and allows team members to share information and coordinate work. It also reduces the time spent searching for information and questions.

One of the best benefits of a task board is that it helps the team prioritize. By organizing tasks, teams can better plan their work and deliver a higher quality product. The dashboard and calendar features enable teams to keep track of deadlines and bottlenecks.

Jira Software, a project management platform, gives teams a high level view of their projects. It provides real-time performance reports and enables teams to map their projects to customizable workflows. It also enables teams to set up roadmaps for their projects.

Monitor project completion dates, costs, and the like

Using a project management software or web developer can help you manage and complete your wares in style. One of the many benefits of using a smarpy is the ability to monitor and manage projects across geographies. In addition to providing a single platform to centralize communications, you can also manage your staff and customers in the same fashion. Some of the best programs are free, while others charge a mere fraction of a penny. Some of the more notable programs include Asana and Slack. Regardless of your budget, there is a program to suit your needs. This list is comprised of a few notable software programs that can handle the lion’s share of your project management woes.

Documentation is essential for your project

Creating a well-documented software project makes it easier for stakeholders to understand what you’re doing. In addition, a properly-documented project can save you a lot of time and money in the long run.

During the development process, you will create several different types of documentation. Each one will have a specific function and should be written for a certain audience.

The first step in writing documentation is to determine what your audience will need to know. Whether you’re writing for an end user or a developer, you need to make sure that the documentation is concise and easy to read.

It’s also important to use terms that are appropriate for the intended audience. Using acronyms and tech jargon can be confusing, so it’s best to write in plain language.

Stumble during the entire development process

Posted on by Josh Freese

Determining user needs can also be a problem. And no wonder – it is difficult for customers to accurately formulate requirements for solutions that do not yet exist. Familiarity with existing product properties can make it difficult for a person to formulate his requirements for new products. User preferences can change dramatically during the development process as competitors introduce new offerings and new market trends emerge.

Therefore, if you strictly adhere to the original plan, no matter how ingenious it may be, you can come to a complete failure. We certainly believe in planning – product development is a complex set of activities that require coordination and attention to detail. But plans should be considered as initial hypotheses that are constantly being revised.

Misconception 1: The sooner we start, the sooner we finish

Managers hate downtime and try to use it to start new projects. Even if a new job cannot be started because people have to finish another project first, managers convince everyone that everything that can be done on a new project today will become work that will not need to be done tomorrow. This forces companies to start more projects than they can realistically complete and dilute resources.

If this happens, the company will stumble during the entire development process. And such slowdowns are harmful, because product development is a perishable commodity: technologies and the market change and go to waste very quickly. The slower the process goes, the more likely it is that its direction will have to be changed. One of the divisions of military development found that the cost and delays in the development of the project grew exponentially with the increase in the duration of its development – and by the 4th power. If the project schedule doubled, the cost and schedule variances increased by a factor of 16.

The importance of reducing WIP is clear when looking at a formula from classical queuing theory, Little’s law. On average, the cycle time is proportional to the queue size divided by the processing speed. If there are 20 people standing in front of you at Starbucks, and the barista is serving five people a minute, then you will be served in 4 minutes. The cycle time can be reduced by increasing the speed or decreasing the number of jobs. Usually, in practice, it is possible to implement the second option.

Some developers carefully control the speed at which they start new work, compare it to the speed at which old work is completed, manage the number of projects in progress, and make sure that once the project is launched, there are enough resources to maintain it. They avoid the temptation to steal resources from ongoing projects to shove them into new ones.

Misconception 5: The more features a product has, the more popular it will be

Development teams often believe that adding features increases the value of a product and removing them decreases it. This explains why products come out so complex. Remote controls are unusable, computers take hours to set up, cars have so many knobs and buttons that they look like airplane cockpits, and even toasters are now made with instructions and LCD displays.

Companies that do not believe that more is better produce products that are elegant in their simplicity. Danish audio, TV and phone maker Bang & Olufsen understands that customers don’t always like to fiddle with equalizer, balance and more to find the perfect combination of settings for listening to music. Their high-end speakers automatically adjust to the songs – all the customer has to do is select the volume.

Convincing companies that “less” can sometimes mean “more” is difficult, because you have to make efforts in two areas of development.

Problem Definition

Talking about the problem developers are trying to solve is the most underrated part of the innovation process. Too many companies devote too little time to it. But this is an important phase – this is how teams understand their true goals and come up with hypotheses that can be tested and refined. The quality of the problem statement dramatically affects the team’s ability to focus on what really matters.

When planning Disneyland, Walt Disney took the time to add new features like other parks. He wondered: how can you provide visitors to the park with a magical experience of visiting it? IDEO and other companies devote entire phases of product development to immersing themselves in the context in which they see the product or service. Their developers read all about markets, observe and interview users, study competitors’ offerings, and translate new knowledge into pictures, models, and diagrams.

Determining what can be hidden or what can be discarded

Teams often want to impress their colleagues and bosses with ingenious technical solutions. Users just want a product that works seamlessly. From their point of view, the best solutions are simple solutions that hide from them the work that developers are so proud of.

One company that understands this is Apple. Their greatest advantage lies in the ability to get to the heart of the problem. As Jobs said: “When you start looking at a problem and it seems very simple, you don’t understand its complexity, and your solutions will be too simple. As you delve deeper into the problem, you see that it is complex. And you come to all sorts of confusing decisions – that’s where most people stop.” But not Apple. “A truly great person will go on and find the key principle at the root of the problem, and arrive at a beautiful and elegant solution.”

Determining which features can be omitted is just as important as determining what needs to be included in the product. Unfortunately, most companies throw all possible features into the heap without considering such important things as customer value and ease of use. These companies cut features solely because of development cost or behind schedule.

Managers, on the other hand, should focus on whether removing one of the features will improve their product, and whether it will allow the team to focus on things that really matter to customers. This can be tested in quick experiments for each of the functions.

Developers often think a product is finished when there is nothing more to add. Their logic must be reversed – products approach perfection when there is nothing to throw away from them. As Leonardo da Vinci said: “Simplicity is the best complication.”

Ethics of the software development industry

Posted on by Josh Freese

However, we digress. So, the software industry is still very young, its ethics are still being formed, and today I would like to suggest thinking about some rules that would be nice to have in it in a hundred years…

Let’s start with overtime – overtime. Actually, to be honest, unpaid overtime is theft. The company is just stealing the time of your life. Unfortunately, overtime is just as common in the software and IT industry as it was in Ford’s sweatshops about a hundred years ago at the beginning of the last century. Even worse, most firms often don’t even have much choice – free overtime is perceived by management as an industry standard, without which it is simply impossible to survive in the competition.

Of course, there are studies (read, say, Tom DeMarco) that overtime does not actually increase the productivity of programmers, but until it gets to upper management … In the meantime, mere mortals like you and me can only accept them as a given, or leave into another profession. Well, or look for rare islands with smart managers.

But what I absolutely hate and do not accept is freeloader managers, freeloaders, who not only force people to work 10-12 hours a day, but also consider it to be due and not worth any compensation. When people work hard for you day in and day out, they are sacrificing so much for you. Have the dignity of paying your bills, at least in part. Give a few extra days off after the release of the product, or let’s say make Christmas week off, or give people a nice bonus. Yes, this does not compensate for all that they have lost, but at least part of it. And it will show that you are grateful to them. If all they get in return is a nice sign on the wall… I think our industry should evolve to the point where it would be like going to the toilet in public, if not stealing at all.

Another commonly accepted aspect of our industry that I think should stand alone in a court of law as a sign of culpability is time-based releases. If you read my article about AIM, the reason for it is the product releases by the deadline. Releasing products on time is the biggest enemy of software quality, it’s the reason software breaks, it’s the reason why products are released with fatal and completely unacceptable bugs, even though people knew about them in advance. In the automotive industry – which, as already mentioned, is a hundred years older than the software industry – not only the manager who released the product, but also the head of the company, would go to court and jail for it. In the software industry, this is still perceived as a common thing.

And what else, do you think, should be included in the ethics of software development and, perhaps, even in the legislative framework?

Google and the Velvet Revolution in Software Development

Google is a company with a non-standard approach. For example, Google has its own file system, and ordinary computer components are used as servers. But at the same time, the now-famous “blank” look of the Google homepage is not a thoughtful decision, but a forced necessity. The creators of the search engine simply did not know HTML, so they had to make the page very simple. Initially, there was not even a “Submit” button, to find something, you had to press Enter on the keyboard.

Nevertheless, now Google is the first candidate for the position of software developer number 1. This is despite the fact that the company is one of the largest clients of AMD and is seriously thinking about designing hardware for its own needs.

The trend that Google has launched and is actively promoting is browser software. Programs for which you do not need to download the distribution kit and install it, just go to the site. Simple and brilliant.

Perhaps the main reason for the success of Google services is its focus on user needs and the highest quality of execution.

Look at the mega-popular Gmail, which excited Internet users at that time with a gigantic mailbox size – as much as 2 gigabytes. Now the boxes have become larger, competitors offer the same or larger volumes, but Google has outrun everyone here too. After all, Gmail is actually a browser software that adapts to the needs of the user.

What about Google Documents? A ready-to-use office suite with collaboration capabilities (you can even see in real time how someone you have given access to makes changes to the document) (it is worth noting, of course, that this is not a full-fledged replacement for Microsoft’s office suite, but perhaps the best , which is for these needs on the Internet).

To organize such a service by standard means, you will need to at least buy the appropriate software, install and configure the server. Here, all you have to do is register.

It is worth noting that the main claim made against Google’s browser software has not been confirmed. We are talking about the desire for a monopolistic takeover of the industry and total control over users, up to the mandatory collection of passport data when registering for services.

Such statements sound quite unprofessional, and besides, they are refuted by actual events – Google, for example, has reduced the storage period for search queries and user cookies. This confirms that the main task is to provide popular, convenient, innovative services designed to bring the IT industry to a new level.

Why Velvet Revolution? A lot of monsters in the IT market supported Google’s initiative. The truth is no one says it out loud. For example, a serious drawback of browser software is that it stops working if the Internet connection is lost.

Software coding style

Posted on by Josh Freese

Encoding style

The practice of fixing a single coding style is common to many established teams. Code guide, code style – it’s all about the same thing. Whether to open curly braces for a single expression in an if, whether to wrap each function parameter on a new line, tabs or spaces – all these ambiguities are helped by the team’s agreement on a single coding style. A uniform code base not only makes it easier for team members to read the code, but also lowers the bar for newcomers to join the project.

Linters are a special class of programs that can help you stick to your coding style. Historical note: Lint is the proper name of a C static analyzer “that reported suspicious or non-portable expressions”. Its name has become a household name for all programs of this kind. Now linters exist for most known programming languages: in the form of separate utilities, plug-ins for editors or IDE features. The coding style is specified by some configuration file that is distributed in the command.

Safety

The topic of information security was briefly touched upon in the chapter on SonarQube. There are also more advanced static code analyzers for vulnerabilities, such as ChechMarx. This flexible and customizable software supports all major programming languages and vulnerabilities. The mechanism of operation is approximately the following: the program code monitors the flow of data from all input points (user input, command line arguments, data from the database) to the output points (UI, reports, database) for the absence of sanitizers. A sanitizer is any function or method that checks the content of an input for legitimacy. If the sanitizer is missing, then the analyzer reports a potential vulnerability. ChechMarx also provides a complete step-by-step chain of data transformations, allowing for a possible vulnerability.

Freeware in the same category: wapiti, nikto

General non-instrumental

Most of the recommendations in this article relate to the use of specialized software to improve one or another aspect of development processes. However, a significant proportion of the tasks of building an effective development is solved not by using software, but by applying methodologies, organizing processes and adopting process agreements.

Development methodology

Using development methodologies helps keep team development organized. If no methodology has been used before, then it is worth thinking about adapting one of them. There are a large number of articles on the topic that will help you decide. I liked these two: issoft.by and geekbrains.ru.

The article is mostly facts, but in this paragraph I will dilute the material with subjective opinion. In practice, in an enterprise, you can most often find a waterfall and various modifications of agile. The first is traditionally hayat, and the second is praised 🙂 In practice, a waterfall can be quite convenient if you enrich it with feedback at each stage. And, for example, major legislative changes with a fixed date of entry into force, affecting several organizational systems at once, are easier to orchestrate in a waterfall. On the other hand, new independent projects can be more convenient to do in agile development mode, especially if the business is actively involved in them.

Releases

Releases will help to plan the load on the team and manage the customer’s expectations – timed to coincide with a specific date of change in the software. A release can be thought of as a cross-system release, a tool for orchestrating development across multiple standalone systems.

In the case of long cycles, the practice of maintaining a release calendar will be useful: a full-fledged schedule of start and end dates for development, testing, and trial operation. One of the planning options is pipeline development, when the development phases of the current and next releases are shifted relative to each other. So individual teams do not stand idle and are always provided with work. Among the disadvantages of this approach is the need to keep in mind several releases at the same time: develop a promising one, fix errors in the current one (and still maintain a productive one).

Note: GitLab has a special entity – Release, however, Milestones can also be used to plan releases in agile mode. I recommend to study both functionalities.

Documentation

Documentation is a fairly ancient practice that accompanies development. It helps create a common information space for the project, allows team members to speak “the same language” and makes it easier for new team members to immerse themselves. There are options in the process organization plan:

create documentation before development (functional requirements) or after (technical description);

entrust the creation of separately dedicated analysts or “load” testers (Robert Martin recommends the latter).

It is advisable to decide on an “onshore” approach, since it can be quite difficult to describe a mature or legacy system from scratch (and is it necessary if the project successfully managed without it?). The most important property of documentation is that it should be useful.

Physically, documentation can be kept next to the system code in a git repository (for example, in MarkDown), in bug tracker / agile board tasks (GitLab, Jira, Redmine), in a dedicated ciki (GitLab, Confluence), in Word documents (in including using sharepoint), etc. It is important to be able to view the revision history of the documentation so that you can look at any moment from the past project.

What’s next?

By this point, the development process can no longer be called chaotic: a history of code changes is kept, there is a culture of writing documentation, the process of delivering changes to target environments is organized, logging and monitoring are configured. However, this is only a basic organization, there is always room to grow. Therefore, I recommend further looking at more advanced topics: CI / CD & DevOps and Docker & K8s.

CI/CD & DevOps

In simple words, CI / CD (Continuous Integration, Continuous Delivery – continuous integration and delivery) is a technology for automating testing and delivering new modules of a project under development to interested parties (developers, analysts, quality engineers, end users). The principle of operation is somewhat similar to a pipeline: the technique performs an integration function, combines the previously listed processes into a single chain, the purpose of which is to deliver the finished product to the end user.

Software development environments

Posted on by Josh Freese

Note: An alternative approach is described in the Docker chapter.

The testing circuit or test environment is a collection of servers and software that completely repeats a productive server. The difference between test and production loops is related to their purpose: as you might guess, test loops are needed for experiments and testing the performance of new functionality without the risk of harming real users.

The industry standard is to have three circuits:

dev – development path. The role of such a sandbox for developers can even be performed by their own machines;

test – test loop (QA). This is where testers can perform pre-release feature checks;

prod – industrial circuit. Direct “combat” contour.

Often you need separate circuits for load testing, trial operation, simulation testing, guest external testing. Ideally, each circuit repeats the productive one in terms of its characteristics, but has settings and integrations appropriate for the environment. Managing this manually is quite difficult, so I recommend using tools like Ansible (read more), chef, etc.

Important: on test circuits, you need to erase sensitive data, as well as replace users and their contacts with fake ones. Otherwise, you risk sending reports and notifications to real users from test loops.

The simplest way to organize test circuits is virtual machines. Once configured, an image can be cloned an arbitrary number of times. This is not exactly my area, so I can’t give a hint here, but the idea as a whole is quite intuitive: “cutting” virtual machines is much easier than setting up an iron server every time.

Autotests

I intentionally did not touch on the topic of unit tests, because the article deals with the scenario of turning an ugly duckling into a swan. In my experience, suddenly introducing unit tests into a project without a culture of writing testable code will not bring any easy wins. On the contrary, the creation of autotests, and some automated test scripts, will help in a short time to reduce the amount of manual labor for developers and testers. I can’t recommend specific software, everything is in the hands of QA engineers and developers.

Exploitation

There is an approach to the production operation of the system, in which the development team is not directly involved in the process, since a separate support team has been allocated for this. Such a division can even be fixed in the regulatory documents of the organization. In this case, you should pay special attention to the topic of organizing logging and monitoring.

Logging

Sooner or later there will be a need to manage logs more technologically. Probably, logging in some form is present in the system code. For example, written to a file or standard output. Perhaps even file rotation is set up (for example, in order to reach the maximum file size), and old files are packed into an archive. Perhaps the main problem with this approach is that the files are physically located in a specific environment (contour), and the developer somehow needs to pull them out from there. Searching by history is complicated, processing a large amount of logs is also complicated. These and other related problems can be solved with the help of special log management software.

The most famous representatives are the ELK stack and Graylog. The main use case involves deploying such a system within an organization and then sending logs from applications and systems to it. As a rule, sending occurs over UDP, so as not to disrupt the operation of applications in the event of a logging system failure. Graylog has the ability to use the so-called. streams – online stream processors that are applied to the logs immediately at the entrance to the log management system. As an example: you can start a separate stream for each circuit.

Monitoring

Monitoring systems will help to keep abreast of the system. The simplest use case is to send various metrics from the application (page loading time and operation execution time, the number of unsuccessful logins, the state of the .NET CLR garbage collector, and so on, everything that is important and interesting to developers or businesses) and observe them live on the dashboard. Standard metrics can be obtained “out of the box” by installing the package, libraries are responsible for sending metrics directly, and for business logic metrics, of course, you will need to add system code.

From free software for solving monitoring tasks, I would recommend Grafana. Borrowed the list of Grafana features from the article:

pleasant appearance;

dynamic update of all data;

visual constructor;

connecting a large number of data source types (Graphite, InfluxDB, Prometheus, Elasticsearch…);

many authentication methods;

the ability to send Alerts ( Slack, PagerDuty, VictorOps, OpsGenie…);

a large number of plugins to expand functionality.

Code quality control

Keeping the codebase healthy is the secret to many successful projects. Robert Martin in his lectures talks about the fact that in development it is not so important to speed up as not to slow down. Maintaining a high rate of change is possible not only due to good architecture, but also constant refactoring, incremental code improvement, and reduction of technical debt. Automated tools won’t do all the work for you, but they will help a lot in keeping the codebase in good condition.

sonarqube

Conducting a code review helps keep the codebase clean and tidy. However, it is usually not possible to review all existing code for errors and shortcomings – it will take too much time. Static code analyzers will help you accomplish this task with the proper level of quality and with little or no effort. I recommend paying attention to the free SonarQube tool:

SonarQube is an open source platform for continuous inspection and code quality measurement.

Once configured, sonar can perform regular code quality checks on bugs, technical debt, information security, and code smells.

As you can see in the screenshot, a full report with a final score for each criterion is displayed based on the results of the check. All major languages are supported, there are advanced paid plugins.