I’m not sure if there are any real metrics to judge the quality of software developers thus no one knows how good they really are. The thing that comes closest to rating a software developer is the feedback from their peers – what do they think about their programming abilities? Generally software organizations don’t invest in a 360 degree feedback thus most of us are always clueless about how good we really are. There is a lot of literature on how to become a better or great developer but there is hardly anything out there to identify a lousy developer. This is an attempt to share some of the top-notch qualities of a lousy developer. Well, think of it as an “Good Developer Anti-Pattern”.
Writes code that only machine can understand. The lousy developers take great pride in writing complex code. There would be no separation of concerns, everything would be one giant ball of spaghetti code, the methods would as long as the Great Wall of China, the variable names would be unintuitive as if an obfuscator had named them.
Never keeps the team informed about milestones.Who gives a shyte!? I ain’t telling nobody about the daily progress. Yes, you would hardly get to know what they are working on until you prod them. Asking status from them becomes such a chore that you shudder at the very thought of it.
Needs to be Micro Managed. They need constant baby sitting from their team mates or their manager about tasks they are working on. They just can’t work independently. Period. You give them their own space and you know things would never get done on time. They would constantly forget their tasks or would deliver code in a haste without giving too much thought to it. To them, bugs or unfinished tasks are the hallmark of a working developer. Yeah, right!
Not a Team Player. Their world is finite and they are at the center of their own little universe. They won’t acknowledge the skills of other team members and think they are the best thing after sliced bread.
Blame Game. Somehow it is never their fault when things go wrong. It’s like the word sorry is not in their vernacular. They always have something or someone to blame when things go wrong rather than admitting to the mistake.
Wastes too much time. Most of them are always busy doing other important things than programming like chatting with their friends, spending time on facebook etc. I just don’t get it. Why would anyone spend killing their office hours than being productive or learning new technologies/reading technical blogs.
The thing is that it only takes a mental switch to turn off these nasty habits and adopt more productive ones provided one is willing to make oneself better.
Can great products be built without having any solid development processes? I don’t know but I can confidently say that it’s a definitive topic for a thesis. Well, we decided to do away with all the development processes for one of the coolest products that we are building.
You did what!?
Yeah, Unbelievable but true.
It must be burning in flames, isn’t it?
As a matter of fact, to the contrary, we not only got done sooner but it works great.
You kiddin’ me, right? It ain’t even 1st of April today?
Nope. It’s sad that we have been conditioned to believe the processes are a panacea to all our software problems and helps build product the right way. Come to think of it, it is probably true to a large extent for certain kind of software projects but you can still make magic without it. It is always about the people.
So, what was the darn process? Or, whatever you are calling it?
Actually, we decided to build the software in an extremely simple yet agile way. Really, it was darn simple. We call it “V1P” – Version 1.0 Process.
Ideate
Sudesh and I spent lot of time envisioning how the product would look like. We did lots of wireframes/HTML prototypes before even laying the single line of code or thinking about design. Once we were comfortable with our idea, we decided to put the features in an excel file.
Plan
We created an extremely simple spreadsheet with all the features and task and divided them in 2 week iterations.
White boarding
We did an extensive white boarding of the design and how different components/layers would interact with each other. And, that was our design.
Communicate
As we were working very closely(ahem..I meant we sit next to each other), we used to have informal stand ups. Well, technically, we were always sitting down while having these meetings. So, more like sit-down stand ups – Huh! Oh well. We used to discuss for 15 minutes regarding the progress and any impediments.
Build Trust
We never went back and updated our status. Doh! The source code was the barometer of our progress. It’s funny what all can be communicated to each other when you trust your team mates and build on each other’s code.
Deploy
Sudesh deployed the code every other day so that we could see if anything was broken. Yup, no nightly build process for us. Come to think of it, I missed this the most. I think going forward, we would have some sort of Continuous Integration like we do in our other products.
Fix and Move Forward
We used to fix bugs before moving to any new functionality.
Rinse. Lather. Repeat.
Well, that was our process. You would be really surprised that we got done with the alpha version of the product in straight 3 months. It’s a fairly complex product and I’m sure it would have taken more time if we were to follow everything by the book. I think the thing that led to our success was lot of brainstorming early on and having immense level of trust.
It’s a different thing if the product becomes successful or not. Well, it’s coming soon. Wish us luck!
PS – I’m sure you must be really thinking that it is really applicable for products which are being built in a garage by couple of hackers. Well, may be. It’s not something that we follow everyday but has produced great results for us. Also, I don’t intend to follow it in our products of fairly large size which need lot of interactions but something I’m ready to stick with for smaller teams.
There are various parameters to judge a developer but for me the number one criteria is efficiency. Ahem…I don’t mean efficiency of writing bad code or providing sub optimal solutions. Far from it.I mean the efficiency to write good code. Readable Code. Extremely Flexible Code. A highly maintainable code.It’s the efficiency with which they passionately latch on problems and solve them. They are efficient because they understand the underpinnings of the programming framework and the toolset they use every day. So, how does one become efficient at developing software or be “The Good Developer”?
I’m not sure if you loved Physics or if you ever understood Einstein’s famous mass-energy equivalence. Well, the one where he proved that mass of a body is a measure of its energy and they are connected by a constant.
E
=
mc2
I hope Einstein forgives me for this. But, in our little software development world, it means
E
= Efficiency
m
= (intrinsically) motivated
c
= Cluefulness
Thus, efficiency of a developer can be defined as their level of motivation to excel times the square of their cluefulness.
True. Seriously. Don’t believe me? Ask Einstein. Can you? You can’t, can you? Then, you really have to trust me on it
What is Cluefulness? It can be defined as one’s expertise and capabilities in developing software. Please read this extremely insightful post by Eric Sink if you want to learn about Cluefulness and how to increase it.
If you one of the developers who are extrinsically motivated by rewards, all-the-things-money-can-buy-kind-of-salary, free beer to write code – tough luck in this life. On the other hand, if you are intrinsically motivated to learn new frameworks, delve into complexities of algorithms and data structures, write code for fun then all you have to worry about it is how to increase your cluefulness.
I won’t repeat what Eric mentioned in his great post but I would mention few things to increase your cluefulness.
Read Code – It’s surprising how less time developers really spend reading other people’s code for learning patterns and anti-patterns. Some developers would keep on writing the code in same style that they learned in school. For real. One can either learn by working with really good developers or reading code of open source frameworks/products. I can’t emphasize enough the value of reading code – Can one become really good writer if they haven’t ever read a good book in their life?
Focus – How can one become good at their art if the first thing they were to do every morning was check their friend stream on Facebook, chat with their long lost friends on their favorite IM, check their emails, any-other-unproductive-activity-except-programming. Shouldn’t the first thing really be to focus on building great software? I doubt if Einstein would have come up with general theory of relativity if he was checking his friend feed on facebook all the time or was being bugged by other Physicists on Skype.
BeInquisitive – One has to be curious and hungry to learn new things, ruminate on hard problems, figure out ways of doing old things in a new way. One would never learn better ways of doing things if one is happy with the status quo.
Tools are your best friend – I’m not sure if a developer could really be productive in writing ASP.NET applications using Notepad. One has to be good at Visual Studio.NET or an equivalent IDE to be really productive at building websites using the ASP.NET framework. Thus, it’s not only enough that one spends the time in learning and polishing their programming skills but also picking up tricks to use the development environment to their advantage. Learn the Shortcuts, write loads of reusable code snippets, know how to use Nuget etc. They are an aide to being efficient and solving problems faster.
Developing a quality software product falls under the realm of software engineering. The ever changing user requirements and harsh project timelines pave way for cost overruns or delays in the delivery schedule. So, bigger the scope of your project, more complex the functionality becomes. With so many factors it is very easy to lose control over the quality processes to develop an excellent product. We know that no engineering is complete without accurate measurements; which further brings us to the point that all measurements are done by applying certain metrics.For this reason we need software metrics for transparent and quality delivery of the product. Because when you measure what you speak about, you have numbers to express your failure or success. You have a calculated expression which shows you where you lacked and places you stood well. In Bob Parsons’ words-‘Anything that is measured and watched, improves.
Now the question arises- which software metrics to use?
One option is to pick a set of predefined metrics. The other one is you can first define the product requirements, discuss with the various stakeholders and then set the required metrics.
For a better understanding, consider an analogy when you are backpacking for an adventure activity. Would you pack a parachute if you are going for kayaking?
Absolutely not.
Instead, you would first decide upon the adventure sport, do a bit of research and accordingly pack your adventure gear. So, if you are going for paragliding, pack your bag with a helmet and a harness.
You can leave the oars behind for the next time.
Defying the law of gravity? It’s okay. But make sure you don’t cause more harm than good in the project. For this reason, it is important to apply the right metrics at the right stage in the product development cycle. As a software development company which builds engaging products.
1. Team Velocity Points
In simple words, team velocity measures the average speed of your team towards achieving its goal during one sprint. The fact that a typical sprint goes on for about 2-4 weeks, calculation of team velocity points proves to be a valid metric to gather the team’s efficiency.
If you want to calculate your team’s velocity, sum up the story points that were completed during that Sprint. To decide the team’s velocity, a three sprint’s average is usually considered.
Why? It’s an industry standard and it determines the project’s pace at which the functionality is being developed. In simple terms, it tracks the velocity of a Scrum team over time. This metric helps in deciding whether the team can take up more work over time or is the team already overloaded and it need to be reduced.
2. Sprint Burndown
Sprint burndown chart is the most effective tracking metric to visualize the health of the project. It helps in reviewing how much work is pending and if the team needs to speed up or slow down. You can also predict the expected completion date of the sprint. A deviation from the expected burndown will send a red flag to the scrum master to take appropriate actions.
For instance, if burndown goes up at any point during the sprint, it reflects an addition to the existing scope. At this time, it’s important for a team to achieve ‘team’s goal’ first before fetching new items from the backlog.
Why? The Burndown chart indicates the progress of work within a sprint. It shows whether amount of work a team is accomplishing every day will lead to a successful sprint completion or not.
3. Release Burnup
Product owners need to evaluate what should be out in the market first based on their discussions with other stakeholders. Release Burnup helps POs to continuously prioritize product backlog based on how the work is progressing.
If the release date is fixed and there has been a few additions to the initial scope, this is an important metric to align scope with the actual release date by either removing low priority backlog items or attempting to increase velocity by taking suitable measures.
Why? The Release Burnup chart indicates whether the sprints are progressing towards a successful project completion in terms of functionality achieved. Also, gives us a projected date of completion of the project.
4. Estimated Cost vs Actual Cost at Completion
Often there are gaps between the estimated cost projection during the start of the project and the actual cost at completion of the project. This metric gives a measurement of what deviations could have led to this difference in the cost.
Although, almost always the project cost goes higher than the expectation (just like we tend to overspend while shopping), this metric helps you understand what could be the possible cause of cost overrun- be it some design error or some changes in the scope of product development.
Why? Helps us understand what cost we had estimated and what cost was incurred. This helps us in improving our planning.
5. Number of major bugs per sprint
The number is an indicator of the overall quality of the product. When you are working in an agile project, it becomes important to put a budget i.e. count on the number of major defects open in a project at any point of time.
How can we stay within the budget? Reduce the count of defects reported.
How can we reduce the number of defects? Do Not Report!
Yes, I’m kidding.
Here is a better solution- focus at the time of planning, look-ahead and clearly define acceptance criteria before jumping on a sprint backlog item.
The priority of resolving any major bug is over and above implementing any new feature. Because if you can’t resolve what your did wrong, you can not pick a new feature.
At the same time, keep a close watch at the number of bugs reported after production release. If you have not been proactive in refactoring and improving quality of your code, chances are you will receive nasty numbers in this metric. This will help you to identify gaps in testing and take corrective measures
MVP in the field of Software Development stands for Minimum Viable Product. It is a concept developed by Eric Ries as a part of the Lean Start Up method. According to his definition:
“The Minimum Viable Product is that version of the new product which allows a team to collect the maximum amount of validated learning about the customer with the least efforts.”
It is based on the idea of Incremental Software Development that renders a product more efficient which is complete on its own with each iteration. A Minimum Viable Product is developed as a core unit of an experimentation strategy. It consists of a basic set of solutions for testing the viability of a business idea and how the customers react to it.
The main purpose of building an MVP :
Deliver a working product that provides immediate value with minimum resources be it money, time or infrastructure.
Create a baseline for future development and clarify the next steps to be taken in the project.
Earliest possible product release.
Minimum implementation costs.
Test the viability of the product before investing large capital and manpower into it.
Identify potential features and failures.
Identify and understand its user base and its preferences.
After receiving feedback, more features can be added. Every new release of the MVP should ensure a better solution for the customers and should be completed rather than a ‘work in progress’ solution. This can be understood better through an illustration by John Mayo in his article ‘Two Ways to Build a Pyramid’.
In a traditional approach, building the pyramid can be started from the base, and a new level can be added on top with each increment. Although this is an incremental process, until the last iteration it is only a ‘work in progress’, as in the image below.
The other approach is to start with a small pyramid. With each iteration, components can be added to increase its size or extend its functionality. Thus, after each increment, you will have a complete pyramid which can be further extended.
The rule here is to add new features gradually with each release of the MVP being a better and faster solution for the agenda under consideration.
Types of MVP
There are two categories of MVPs. Low Fidelity MVPs help you to get an insight into your customer’s problems and the kind of solution that will be most effective for the customer. High Fidelity MVPs are used to find out how much the customers will be willing to pay for the solution. Furthermore, it helps you to optimize your marketing strategy and communication channels along with the best potential growth strategies.
In today’s market where a wide range of services and products are in demand, minimum viable products differ accordingly. The different types of MVPs which can be categorized under Low-Fidelity and High-Fidelity MVPs are as follows:
Low Fidelity MVPs
High Fidelity MVPs
An Honest Customer Interview
Digital Prototypes like wireframes and mock-ups
Blogs and their Comments
3D Models for manufacturing products.
Subject Matter Forums
The Wizard of Oz
Website or an Application Landing Page
The Concierge MVP
Split Testing to measure user reaction to changes
The Piecemeal MVP
Videos
Crowdfunding helps generate funding for the product creations as well as testing its future demand in the market.
UX Prototypes.
Single Featured MVP in order to focus on the most essential solutions that will be provided by the product.
Ad Campaigns for market surveys
Email MVP
User SignUp for an Upcoming Product
Audience building via tests, interviews and questionnaires.
Micro-Surveys
Out of the above MVPs, most of which are self-explanatory, let us elaborate on the following few.
Concierge MVP: Here building a product is not necessary. Here you provide the services manually and analyze your customer interaction. This helps to understand if the customers will use your product or they need an entirely different product.
Wizard of Oz MVP: Here a fully functional product prototype is presented before the user while you are at work behind the scenes providing all that is necessary. Through this type of MVC, you are able to interact directly with your customers and review their preferences.
Piecemeal MVP: Here existing tools and solutions are used to create your product. This involves a minimum or no investment. A piecemeal MVP consists of existing components from multiple third-party sources that are put together to create the product or service.
Email MVP: Here you begin by sending emails with the business proposition to your existing customers. If the feedback is positive, the business idea is worth pursuing, however, if the feedback is bleak, either the proposal is missing something or it does not solve any problem.
Pitfalls
The main pitfall of an MVP is its lack of understanding. More often teams tend to believe it is the smallest amount of functionality that needs to be presented to the consumers in order to understand its viability. It might also be confused with minimum market earning. MVP is more focused on learning from customer feedback. It is very important to identify the set of features that needs to be included for an MVP. Including too many features will overload the MVP, incur cost and time and may fail to succeed. However, filtering features may cut out its key functions. The basic set of solution repeatedly mentioned here, refers to developing a deployable product with the key features which allows customers to access the solution and complete their entire journey towards their goal. Hence, it is essential that before releasing an MVP teams correlate the terms ‘minimum’ and ‘viable’ correctly. Finally, always keep in mind the metrics – Daily active users, maintenance rate and the average time spent with the product in order to quantify the success of your MVP.
Conclusion
Developing an MVP is a strategy to avoid developing products that are liable to be rejected by consumers. It is basically built to test a specific set of assumptions and prove that the product will provide an effective solution. MVPs are effective only when you take into account market feedback. This will help you to understand which features are to be developed and which to be discarded. While developing an MVP always keep in mind the most accurate but least features of the product but not the complete product.
Mobile device users are rapidly becoming the user’s favored instruments of choice for browsing the Internet. With market leaders centering on providing customers with exceptional user experiences, we are now seeing a rapid rise in consumer expectations, which compels, including the innovation of the mobile experiences you offer. Just implementing a mobile-first approach isn’t sufficient anymore. While your users may make-do with a responsive website in the early period, a shift to mobile apps provides you substantial leverage over your contemporaries. The key to successful mobile applications isn’t just limited to excellent design and continuous development. The development teams need to speed up the delivery of benefits that mobile apps offer to users. Implementation of the agile procedure, adopting a DevOps strategy, and making a move to the microservices model of creating a cloud-based application gives you a unique business advantage. Microservices enable the development teams to own the entire project development cycle. It provides much-needed flexibility in mobile app development services. Teams can work upon the data collected from users to incorporate changes within the app components on a real-time basis resulting in the DevOps procedure becoming more dynamic and the development teams more agile.
Flexible integration and code creation suit rapidly changing, customer-facing apps, which pushes businesses to evaluate microservices for mobile applications. Microservices in mobile application development boost modularization — breaking the architecture apart into independent services and groups of services. With services lined up around business function and still secluded from each other, developers can deliver the quick updates and recent feature releases that mobile users expect. Since microservices communicate via APIs, mobile application developers can opt for the most appropriate technology stack and language for each service or business flow, instead of limiting the entire project to one. However, microservices aren’t the only way to business mobile app development. Low-code platforms also tout a simple procedure to build mobile apps.
What are Microservices?
Microservices architecture is an essential architectural innovation that is a useful alternative for building complicated software applications. It involves the fragmentation of large applications into loosely coupled smaller services. Each microservice focuses on separate business functionality. Every microservice can be independently deployed, tweaked with, and redeployed without compromising the application integrity — the loose combination of microservices lead to the facilitation of rapid deployments. The features build as a result of user feedback, thus quickly reach the users.
How do microservices differ from conventional development practices?
In the conventional monolithic app architecture, designs all the constituents of the code as a single, cohesive unit in which the constituents are independent and interconnected. Any updates the developers require to make results in alterations made to the whole stack. Adopting a new framework or shifting to a new tech stack needs a substantial overhaul and rewriting of the entire code. In contrast, microservices architecture has the system distributed into individual services that can run as autonomous processes and communicate with each other, utilizing APIs. Containerization enables the encapsulation of the services, and operations run in parallel, thereby making the existing infrastructure easy to maintain. Any changes or updates performed on individual services without affecting the entire system.
Benefits of microservices architecture in app development
Improved productivity and agility
Microservices are made, deployed, and tested individually of other components in the system, which results in enhanced team agility and rapid iteration cycles. The developers have the elasticity to use the framework or language most appropriate for the functionality developed; this ramps up productivity by radically reducing the amount of code to be written. It also increases the maintainability of the application. Breaking down complex apps into manageable services improves the performance of agile teams.
Accelerated velocity and scalability
Scaling of various microservices components at runtime takes place individually; this facilitates more productive resource utilization. We can shift the workload of an element to an infrastructure that is best suited for the task. Microservices offer accelerated development speed combined with on-demand scalability. The flexibility of the cloud-native environments can be effortlessly leveraged by the microservices making scaling cost-effective through optimal use of infrastructural resources. Microservices also ensures that the application is more responsive to market requirements. The agile methodology enables you to roll out robust digital capabilities in response to real-time market requirements.
Continuous deployment
In conventional monolithic systems, dedicated teams work on distinct functions. The introduction of microservices leads to cross-functional teams managing the complete application lifecycle in a continuous delivery model. With various team members, including testers, developers, and operations teams working simultaneously on a development testing, single service and debugging takes place in continual iterations. The incremental development results in a constant cycle which writes, tests, and deploys the code consistently while incorporating relevant feedback.
The rise in cross-functional teams
Carrying out software development and deployment could be a tedious job when, while working with extended teams. Microservices result in improved independence for the developer. They can work independently, resulting in faster decision making. The cross-functional teams in microservices architecture consist of empowered individuals who can make faster decisions. Working in smaller groups and close-knit teams result in more freedom to the individual team members and quicker technical decision making.
Flexibility in utilizing technologies and access to a broader talent pool
Since each developed microservice can be written using different technology, the development team is free to opt for the tech stack that would be most suitable for the specific service. Decoupled services written in various programming languages can easily coexist, add new components continuously, and perform scaling at an individual level. The flexibility that microservices offer also enables you access to a broader talent pool.
Summary
While the business profits of shifting to a microservices architecture are huge, the transformation needs to be sensibly monitored and strategically implemented. Implementing a DevOps culture, with robust monitoring is essential for an effective shift to the microservices architecture. The ramp in flexibility and speed has to balance with an associated increase in complexity.
DevOps is no magic, but it can definitely look like it from the outside. In today’s corporate world, workers in the innovative fields are generating new roles for themselves. The role of the DevOps Engineer is one instance of such. There’s a lot of misconception regarding who is a DevOps Engineer? Are they the person who writes the code or are they responsible for the work of a system engineer? Well! Not exactly. Through this post, I shall guide you through the roles and responsibilities of a DevOps Engineer.
What is DevOps?
DevOps is the blend of cultural philosophies, tools, and practices that increases an organization’s ability to deliver services and applications at high speed: evolving and upgrading products at a faster rate than organizations using traditional software development and infrastructure management procedures.
This speed facilitates organizations to serve their customers better and compete more efficiently in the market. DevOps culture is introduced to create better collaboration, improved communication, and agile relations between the Operations team and the Software Development Team. Under a DevOps model, the gap between the development and operations teams is bridged. Sometimes, the two teams are merged into one team where the engineers work through the entire application lifecycle, from development to test and deployment to operations, and develop a set of skills not limited to a single function.
The teams make use of practices to automate procedures that traditionally have been slow and manual. These tools also support engineers to independently achieve tasks that normally would’ve required help from other teams, and this further enhances a team’s velocity. Simply put, DevOps is a set of practices that combine Software Development (Dev) and IT operations (Ops) which intend to shorten the systems development life cycle and provide continuous delivery with high software quality
Unlike popular opinion, DevOps is not:
a combination of the Development and Operations team.
a tool or a product.
a separate team.
automation.
However, DevOps is a process that includes continuous:
Integration
Development
Testing
Deployment
Monitoring.
Understanding the role of a DevOps Engineer.
The DevOps Engineer is truly a revival of the cloud infrastructure IT services. It is often strenuous to understand this role because the DevOps Engineer is the product of the dynamic workforce that has not yet finished evolving.
DevOps professionals come from a multitude of IT backgrounds and begin the role in different places in their careers. Generally, the role of a DevOps engineer is not as easy as it appears. It requires looking into seamless integration among the teams, successfully and continuously deploying the code. The DevOps approach to software development requires recurring, incremental changes, and DevOps Engineers seldom code from scratch. However, they must understand the fundamentals of software development languages and be thorough with the development tools utilized to make a new code or update the existing one.
A DevOps Engineer will work along with the development team to tackle the coding and scripting needed to connect the elements of the code, such as software development kits (SDKs) or libraries and integrate other components such as messaging tools or SQL data management that is needed to run the software release with operating systems and production infrastructure.
A DevOps Engineer should be able to manage the IT infrastructure in accordance with the supported software code dedicated to multi-tenant or hybrid cloud environments. There’s a need to have a facility for required resources and for procuring the appropriate deployment model, validating the release and monitoring performance. DevOps Engineers could either be the system administrators who have moved into the coding domain or the developers who have moved into operations. Either way, it is a cross-function role that is seeing a huge upward trajectory in the way software is developed and deployed in object-critical applications.
It isn’t rare for DevOps to be called to mentor software developers and architecture teams within an organization to educate them about how to create software that is easily scalable. They also work with the security teams and IT to ensure quality releases. Some DevOps teams include DevSecOps, which bids DevOps principles to driven security measures.
The DevOps Engineer is a significant IT team member as they work with an internal customer. This includes software and application developers, QC personnel, project managers and stakeholders usually from the same organization.
They rarely work with end-users, but keep a “customer first” mindset to comply with the needs of their internal clients. A DevOps Engineer is a customer-service oriented, team player who can arise from a number of different work and educational backgrounds, but through their vivid experience has developed the right skill set to move into DevOps.
Tasks of a DevOps Engineer.
Typically, the role of a DevOps Engineer comprises of the following duties:
Work with a variety of open-source tools and technologies for managing source codes.
Deploying multiple automation tools of DevOps to perfection.
Continuous iteration of software development and testing.
Connect to business and technical goals with alacrity.
Analyze code and communicate descriptive reviews to development teams to ensure a marked improvement in applications and on-time completion of projects.
Design, develop, and implement software integrations based on the user’s review.
Apply cloud (AWS, GCP, Azure) computing skills to deploy upgrades and fixes.
Troubleshoot production problems and coordinate with the development team to streamline code deployment.
Conduct systems tests for performance, availability, and security.
Collaborate with team members to improve the company’s engineering tools, data security, systems, and procedures.
Optimize the company’s computing architecture.
Troubleshooting documentation.
Implement automation tools and frameworks (CI/CD pipelines).
Develop and maintain design
Understand the needs and difficulties of a client across development and operations
Formulate solutions that support business, technical strategies and organization’s goals.
Develop solutions encompassing technology, process, and people for continuous delivery, build and release management, infrastructure strategy & operations, a basic understanding of networking and security
Implement and recommend solutions.
Expertise and knowledge in current and emerging processes, techniques and tools
Build the DevOps practice within ThoughtWorks and drive our thought-leadership externally
Timely identification and resolution of problems.
Design, develop and maintain the CI/CD tools and infrastructure to deliver Horizon Cloud Service
Skills required for a DevOps Engineer
A Bachelor’s degree in Engineering, Computer Science or relevant field.
3+ years’ experience in the software engineering role.
Expertise in code deployment tools (Puppet, Chef, and Ansible).
Expertise in software development methodologies.
Experience of server, network, and application-status monitoring.
Ability to maintain Java web applications
Strong command on software-automation production systems (Selenium and Jenkins).
Knowledge of Python or Ruby and known DevOps tools like Git and GitHub.
Working knowledge of various databases like SQL (Structured Query Language).
Problem-solving attitude.
It is essential to understand that a DevOps engineer is built out of the growing needs of the business to get a tighter hold of the cloud infrastructure in a hybrid environment. Organizations implementing DevOps skills yield better advantages such as spend relatively less time on configuration management and faster deployment of applications. Demand for people with DevOps skills is growing exponentially because businesses get great outputs from DevOps. Organizations utilizing DevOps practices are overwhelmingly high-functioning: They deploy code up to 30 times more often than their competitors, and 50 percent fewer of their deployments fail, according to 2013-2017 State of DevOps.
Why is remote software development expensive?
While we are speaking to our prospective clients about their product development plans, one comparison that often gets discussed is why they should even outsource to us and not hire an in-house team?While there are many other factors in comparing remote vs in-house software development, one of the important factors in this comparison is the overall cost.Though seasoned entrepreneurs may understand this very well, as a first-time entrepreneur, it’s easy to miss out that when you are hiring a company for your software development, you’re paying for a finished product.
And a “finished product” is a lot more than the code that gets pushed on your servers. Here’s what all goes into building successful software:
Team salaries: The salaries paid to the team working on your product is the most obvious expense and hence this is the first item on this list. Duh!
Office space: A clean, well maintained IT office at an accessible location with all amenities including Internet connectivity, meeting rooms, projectors, whiteboards, pantry, etc. is a constantly recurring cost borne by the company.
Hardware and software licenses: The employee’s laptops and networking equipment, both of which require routine upgrades as per market standards is an important recurring cost an IT company has to bear. In addition, many software licenses and SaaS tools and services (ex. email services, testing servers, OS licenses, etc.) have to be paid for on a month to month basis.
Admin overheads: Admin and maintenance staff and office supplies needed for day to day office operations may seem like small expenses in isolation but quickly start to add up.
CA and Accounts: Any software company will need an accounting and CA services to handle their routine compliances, taxes, and payrolls.
Hiring and training costs: Hiring and training people is a stressful, expensive and time-consuming task. Not only is the hiring process difficult, but every organization also has to deal with the problem of employee churn. Every IT company also needs to spend considerable time in training and upgrading employee skills as per current trends and market expectations.
Team activities: A happy and satisfied team is much more than just offering market-rate salaries. Today’s workforce looks for perks, team activities, etc. and as an employer, these are important team building and retention strategies.
Operating profit: Over and above these costs, the software company will keep a profitability margin which will make the business sustainable over the long run.
If you are starting up, it may be a better idea to simply outsource all of the above to a software company so that you have only one thing to focus all your attention on – Your product
IT outsourcing is notoriously known for false promises, sub-standard quality of software and an inability to deliver products that can actually be used.
We discovered that more than half of our clients have burnt their fingers with such IT companies before choosing Anteelo and finally getting software delivered in the way it should have always been.
This post is based on true stories and is a compilation of the most common and shocking stories and experiences we have heard from our clients over the past few years.
1. False promises by sales teams
Often, the first meeting with any IT company will be with people from their sales team, who are usually non-technical and may not understand your business problem, vision, and product at all. However, they have been trained and groomed to say the right set of words which sound convincing and make you decide in their favor.
In such meetings, the sales team also tends to commit and agree to many terms which are then rarely delivered in practice. Most of the times, the complexity and understanding of what is being committed to being completely missing.
2. Deep organizational hierarchies
Most companies will never get you in touch with the set of developers and designers who are going to ultimately work on your project. That communication is often forced to go through product managers, project managers, team leads and various such roles where everyone adds their own subjective interpretation leading to a lot of important decisions just getting lost in translation.
The reason for this obfuscation is that most companies would hire very junior or young developers with incompetent design and software development skills and provide them with zero training. Often they are learning on the job as they are building your product, which means that the code quality being delivered is poor and the product is riddled with a large number of bugs and issues, often leading to an unsatisfactory and unusable project.
Another common scam is further outsourcing your work to another company without your permission. That means that the quality of work goes down even further since the communication gap widens. Also, it can be assumed that in most cases, the second company will be even cheaper and that will reflect in their hiring and quality standards as well.
3. Not sharing source code with clients
Since most clients of IT companies are non-technical, IT companies would often take advantage of the fact that the client’s entire source code is under their control. The unsuspecting client is also unaware of the importance of this ownership until things turn sour in the relationship. Source code transfer often becomes the hostage before the scores are settled.
4. Charging exorbitant hosting fees
Taking advantage of the nontech awareness of their clients, many IT companies would charge a hefty monthly fee in the name of server hosting, etc. even if the same can be done at a much cheaper cost. Most clients will simply give-in because they will not understand the correct facts and have no option left but to believe what they chose IT company is suggesting.
5. Fake claims about skills and clientele
Websites of most IT companies claim to have great competencies, skills and clients listed. While most of them may be true, but most people get fooled into believing that the company has built the whole product for the clients they have listed.
As a client, always ask for the details of what the company did for that client. Did they work on their whole product or a part of it? What exactly was their role and how long was their engagement? Demand for answers to be explained to you in a simple non-technical way.
6. Delivering software as per spec, but not as per common sense
Most companies will ask their clients to create a product spec or requirements document to define exactly what they are trying to build. And the IT company will share a time and cost estimate accordingly. But no company will bother to improve the spec or explain the shortcomings in the document to the client. Often there would be features in the spec which may not be that important to the client but would take significant development time. Nobody in the team (sales or development) would take the initiative of asking the client whether such features are important or can be skipped.
Eventually, a combination of a vague product spec and a team of incompetent developers means that the product will never be completed. Most companies will just get into a never-ending cycle of bug fixing where one bug fix leads to another and months go by and nothing is ever ready to ship.
Even in the rare case that the product is actually completed, it may tally to the spec document on a point by point level, but the overall product will be unstable and practically unusable.
7. Delivering software which will crash as soon as actual workloads start
Lack of proper testing across a variety of devices and platforms leads to issues which can be hard to detect until it’s too late. Often the developers and sales teams will be smart enough to show you a product demo in a very limited and controlled environment but the moment the product will go live, everything will begin to fall apart. Your users will complain of your app crashing on their phones or not working as expected.
Such issues are even more devastating since by then you would have already announced your product to your connections and damage control would be nearly impossible.
It’s important to evaluate your IT company on multiple factors, not just the final price. Making a good choice could lead to an association that could last for years and helps you with your product and startup vision for a long time. A bad choice could mean that your startup ambition could fail even before it lifts off from the ground.
/software-developer-job-description-salary-and-skills-2061833-Final-c1443780296e40869075925f9b96fb5e.png)
