RedMonk Language Rankings

RedMonk Language Rankings

Downhill Spiral of Atlassian Tools

Once hailed as essential pillars in software development and project management, Atlassian's suite of tools—Jira, Confluence, Bitbucket, and others—appears, for many, to be on a perceived downhill spiral. What were once celebrated as robust solutions have, over time, increasingly transformed into sources of profound frustration, hindering productivity rather than enhancing it. The ubiquity of these platforms now seems less a testament to their inherent excellence and more a reflection of their entrenched market position, as users and administrators alike wrestle with a growing list of grievances that paint a picture of steady deterioration.

At the heart of this perceived decline is the issue of unrelenting complexity and feature bloat. What began as a flexible framework has metastasized into an unwieldy behemoth. Jira, in particular, has become infamous for its labyrinthine configuration options, intricate workflow schemes, and convoluted permission settings. While this extensive customizability is theoretically powerful for large, complex enterprises, it imposes an exorbitant administrative burden that often far outweighs its benefits. Smaller and medium-sized teams find themselves drowning in a sea of unnecessary features and arcane settings, requiring disproportionate time and dedicated personnel simply to maintain baseline functionality. This overhead not only saps resources but also creates a significant barrier to entry and adoption, pushing away potential users overwhelmed by the initial learning curve.

Compounding this complexity, performance bottlenecks have become a chronic and escalating problem. As Atlassian instances mature and accumulate more data, users, and projects, their responsiveness often plummets. Slow page loads, agonizingly long search times, and general sluggishness when navigating dense information are common complaints. This isn't merely an inconvenience; it directly translates into lost productivity and heightened user frustration. The constant need for costly hardware upgrades, intricate database optimizations, or a forced migration to their cloud services (which come with their own set of costs and data management concerns) highlights a fundamental scalability challenge that often feels inadequately addressed, turning daily operations into a test of endurance.

Furthermore, the user interface (UI) and user experience (UX) often feel like a relic, especially when compared to more modern, streamlined alternatives. Despite sporadic redesigns, the Atlassian ecosystem frequently presents a disjointed and unintuitive experience. Navigating between applications—from a Jira ticket to a related Confluence page or a Bitbucket repository—can feel like jumping between different software generations. Essential functionalities are often obscured or inconsistently placed, requiring users to memorize non-obvious pathways rather than instinctively engaging with the tools. This lack of a cohesive, intuitive design language significantly contributes to the perception that these tools are fighting against the user, rather than seamlessly supporting their work, demanding exhaustive training rather than fostering organic adoption.

Finally, the escalating cost factor represents a growing deterrent. What might initially appear as a manageable investment quickly balloons with the necessity of add-ons, integrations, and the tiered pricing models for growing user bases. Organizations often find themselves ensnared in a vendor lock-in, where the extensive data and deeply embedded workflows make migrating away from Atlassian an economically and operationally prohibitive endeavor. This creates a captive audience, forced to absorb rising costs for tools that, for many, are increasingly failing to deliver on their promise of efficient collaboration.

The journey of Atlassian tools, from industry darlings to objects of widespread exasperation, reflects a failure to balance comprehensive functionality with user-centric design and consistent performance. The very strengths that once defined them—extensibility and feature richness—have, for many, become liabilities, manifesting as overwhelming complexity, crippling performance issues, inconsistent user experiences, and unsustainable costs. For a significant segment of its user base, the dream of streamlined collaboration has devolved into a daily battle against cumbersome and frustrating systems, casting a long shadow over their continued dominance in the market.

Are we Game Yet

Are We Game Yet

Fake Devops Engineers

• Takes them 1 to 2 months to spin an instance on the cloud when it should take a couple minutes at max (the whole process literally takes a few seconds on most cloud environments), apart from additional time for setting up security groups which should take 2 days or possibly a week.
• Negating everything you say, then using your suggestions as their own
• Taking longer than is normal to provision and setup an environment
• Having excuses for everything when things go wrong
• Playing blame games
• Not provisioning sufficient monitoring and automation services
• Have they ever attended a devops conference?
• They prefer windows to linux environments
• They get frustrated very quickly at the most silly things
• They confuse ops with devops
• They find it difficult understanding that any regular polygon can fit into a square (this is a typical case of being able to understand abstractions which even works at identifying a fake architect)
• Don't understand infrastructure as code
• Don't understand the relationship between development and operations
• Don't understand how to manage and use automation
• Don't understand what small deployments means
• Don't understand what feature switches mean
• Don't understand how to use nor heard of Kanban, Lean and other Agile methods
• Don't understand how to manage builds and operate in a high-velocity environment
• Don't understand how to make sense of automation, tools, and processes
• They don't understand the devops workflow
• They lack empathy
• They don't understand trunk-based development
• They don't understand what a container is used for
• They don't know how to manage an orchestration process
• They don't know how to manage a staging environment
• They don't know what serverless means
• They don't understand difference between microservices and monolith
• They don't understand immutable infrastructure
• They don't know what type of devops specialist they are
• They don't know how to create a one-step build/deploy process
• They don't know how to instil trust and respect
• Not having any favorite devops tools
• Not having any specific devops strategies or best practices
• How do they decide whether something needs to be automated
• They find it difficult to solve issues when things go wrong
• They find it difficult to embrace failure and learn from their mistakes
• They have difficulty in problem-solving in production environments
• They find it difficult to link up tools and technical skills with culture and teamwork
• They have a big ego vs a humble nature when it comes to self-characterization
• Someone that over-compensates on self-promotion but does not acknowledge their deficiencies

Awesome Big Data

Big Data has taken off in leaps and bounds for distributed systems as well as machine learning. The following links provides useful set of curated and category list of Big Data frameworks, libraries, resources, and other related technologies. No doubt this will change as the domain has proven to be very dynamic.

Awesome-BigData

Big Data

Hadoop Ecosystem
Big Data Ecosystem

Outsourcing Development

Many companies look to outsourcing as a means of cost efficiencies and for rapid turnaround of work. On other occasions it is about lack of in house skills for which they need to outsource for support. Although, outsourcing may appear to increase development efficiencies in short-term, it more than reduces it in the long-term. Outsourcing is also detrimental to agile processes within a team environment. It also ordinarily reduces the scope of development work for existing permanent staff which inevitably leads to loss of morale and productivity. Although, management might see outsourcing as the way to go, for many developers it is often an unpleasant experience. Not only does outsourcing incorporate frustration with third-party communication but it also involves lower quality as well as increases risk for unexpected delays in project deliveries. Invariably, with outsourcing one is also limited to the skills and experiences of the third-party for development. On many occasions once a project is delivered, third-parties also play tricks to continue on the contracted work with continued maintenance or for more project deliveries as a form of business opportunity. While the product owner values quality assurance, the third-party outsourcing agency more than values delivery of work for which they are paid. At times, delaying work also means more income from the product owner. On other occasions delivering on buggy projects means more continued work for maintenance later down the line. All this stretches the budget constraints on an outsourced project and for the product owner. The best approach for most corporate environments looking to deliver on project is to bring in permanent developers for the entirety of the full life cycle of work. This will mean a clean execution of development work with clear deliverable as well as a chance to form an agile culture that grows internally as the project evolves over time. It also avoids wasted time for the product owner as well as for development staff. Most hands-on developers that enjoy development work will never be in favor of outsourcing or contracting work out because it reduces the scope of their work and increases risk of uncertainty. Cloud computing has also allowed for more efficiencies in development with performance and scale to meet business demands for growth. Organizations that utilize outsourcing as their core means of development budgets really need to start re-evaluating their strategy for the long-term as having internal development teams will far surpass in quality of work as well as provide for continued cost efficiencies. In the long-term, this is almost a necessity especially with the changing trends in technology and the demands of the business environment for maintaining a competitive advantage.

Hack Summit

A virtual hack summit conference is happening soon. An almost virtual world of programmers getting together to share the knowledge within the world community of like minded individuals. A Dzone member can obtain a free promo code. However, a donation for admission is highly advised to support such worthwhile non-profit coding charities. Virtual summits make it accessible for everyone around the world to get together from the comfort of their own surroundings and the pressures of the daily lives while saving themselves from the travel expense. Further details can be found at the below links.

hacksummit

hackhands

Packer

Packer is another useful tool for machine image configuration management as well as an alternative to Dockers for virtualization. With Packer, identical images can be produced for machines and multiple platforms using basically a single configuration which is useful for Devops work in the cloud environment. Parallelization in cloud for Big Data has also become important aspect for handling Big Data requirements. Additionally, plugins provide further extended flexibility in the tool. Even Packer images can be converted into Vagrant compatible boxes. As a template one can then build multiple Packer images which does not include the life cycle management of such image builds from how and where they are run. 

Rundeck

A potential devops contender is Rundeck which provides for a multitude of functionality for operational automation of applications. A minimalist user interface is all that is really needed for a hands-on developer and comes with batteries included from access control, to job scheduling, as well as defining entire workflows of commands and scripts that can work across nodes. Rundeck could facilitate the point of automation as a link between continuous integration and deployment. The platform even comes with an API and a diverse set of useful plugins. Finally, the services are free for use which is another mouth watering feature. 

Docker

Building to linux containers makes portability and deployment easier with Docker. The approach is to build applications inside isolated software containers for automated deployments to cloud environments. Thus, easing packaging of application and their dependencies within virtual containers that can run as isolated instances on environments with different linux distributions. The engine has many points of integrations with various infrastructure libraries and frameworks.   It is obviously an alternative to the standard virtualization approach in the market. One aspect to the project that is core to the ethos is that features take a back seat over quality. The tool was developed as part of the dotCloud PaaS project. The approach to lightweight portable applications that can run in-container means better options for scalability, portability, and lower overhead costs, at same time easing the process of maintenance between physical and cloud architectures. The approach is in some ways similar to Solaris Zones. However, in Docker the underlining approach is on linux containers. Rather than building applications to a system software, one then builds to a container. This container has no OS but is able to share the OS from its host. Such containers are faster and less resource intensive than standard virtual machines as far as one limits to a single host to provide the shared OS. The launch time is also improved from a matter of several minutes to fraction of a few seconds. The complexity of configurations is wrapped around an interface abstraction. They have become quite appropriate for mission-critical applications. Initially, supporting Linux distributions only, the project has ventured into cross platform support as well with use of hypervisor.

Docker Developer Tools:
Flynn
Deis
Dokku
Kubernetes
Panamax
Shipyard
Drone
Serf
Fig
CoreOS

Effective Design and Development Comes With Experience

No matter how many books one reads, if one does not have the practical skills to know how to use them they will struggle to apply them in any practical solution to a problem. It seems at times people may ponder at the fact that standing on shoulders of giants can give one the benefit of the doubt and experience, however, in development the only real experience one can achieve is the extensive practical applications one develops and the manner in which they are developed. Applying principles is fine but knowing when to apply them is key. Often times, developers follow the trends in technology and how so many are using them, and then they start to get on the bandwagon without fully grasping the applicability of such technology to their design. Being creative with the tools one develops an application is all fine and keeping them cutting edge and ready for future, but one needs to level of with the sense of whether the complexity is really worth it and whether they really are best tools for the job. One has to take authority figures with a pinch of salt when asking them about their opinion on the applicability of particular technology to an application. Again only the person that is responsible for delivery, has awareness of the business requirements, the cost benefit analysis, and the team experience knows what would be idealistic and realistic towards the expectations for an application development process and design. It seems inspiration and innovation go a long way in allowing one to think outside the box. However, what really needs to be delivered are requirements which are often set in stone to a degree. No one technology will ever be right for every job at hand so careful analysis, consultation, research, and prototyping are often the best ways forward towards a cycle of progressive implementation. It is a lot more important for one to prove to themselves what technologies can be realistically realized and also accepted by the team and business. At times this may call on one to sell the technology to fellow developers or product owners as a viable option. But, in end it is the product owners that have the final say even so far as the time they allow for a convincing case to be presented. Effective design skills do come with experience not only of one developer but of the collective. It is by doing that makes one garner those skills and experience to really see how something works and or doesn't work. A good developer thrives on producing results and delivery consistently through tested code, following the processes, and methods. A great developer takes their role further and embarks on their view as pragmatic team player, knows what they are developing will essentially be used by people, has a sense of persistence, skillful at being able to pinpoint problem-solution approaches, has a massive appetite for learning, knowledge, and constant improvement, and further is able to take the development of an application into a new way of doing things which often times prove to be effective in driving team and business transformation.