Alternatives to Zoom and Teams

Eventhough, Zoom and Teams are popular and fairly standard collaboration tools used across organizations, they can be quite boring to use.  There are plenty of alternatives that can be used instead.

• Around
• Slack
• Vowel
• BlueJeans
• GoToMeeting
• Miro

Office Search

office search
hubblehq
complete office search
prime office search
workspaces
flexioffices
free office finder
office genie
coworker
croissant
included.co
instant offices
pickspace
share desk
happy desk
desksnear.me
desktime
coworking
desk pass
copass
coworking wiki
desk surfing
near desk
liquid space
gocowo
find workspaces
sneed
ofixu
qdesq
share your office
spacelist
42 floors
office list
coffices
breather
peerspace
bizly
spacewhiz
beewake
awfis
all office centers
splacer
lexc
desk camping
worksnug
seats 2 meet
coworking.coffee
commercial cafe
preferred office network
heydesk
office freedom
flexas
kontor
labs
spacesworks
thebrew
cowork

Help Choose Implementation Stack

TodoMV*
TodoBackend

Awesome Django

Awesome Django

Clever Cloud

Clever Cloud

Online CI Providers

Hosted Continuous Integration is a hot area but also a very competitive domain. While some choose to have it hosted in the cloud others like to have more corporate autonomy with using such tools as Jenkins and TeamCity. Continuous Integration is an agile work flow practice that involves developers to integrate on code, in shared repositories, and utilize automated tests to verify for build quality, in order to allow teams to check for issues, early and often, on a daily basis. A step further in the Continuous Integration process is Continuous Delivery. Continuous Delivery being the hardest bit to fully achieve on a large complex architecture and may even prove to be foolhardy. Although, CI has been around for years, it really boils down to team dynamics and whether one really has the time to manually setup and monitor builds in comparison to a hosted option. In some corporate environments, teams may even have a dedicated team member for build and configuration management. The following is a list of a few hosted Continuous Integration providers and the different use cases that they provide for an agile software engineering process. 

TravisCI
DroneIO
CircleCI
BuildHive/CloudBees
SemaphoreApp
ShiningPanda
Hosted-CI
Bamboo
CodeShipIO
MagnumCI
SnapCI
SolanoLabs
ShipIO
Shippable
Wercker
Appveyor
ZeroCI
dployIO

Comparison of continuous integration software

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.

Python Testing

Python testing has gained sheer ground in the last few years as influenced from the Ruby and Java communities. Agile approaches to Python development works seamlessly within teams even with adaptable test-driven and behavior-driven as active methods. There is a growing amount of libraries and frameworks for testing now becoming available for Python and even directly integrated with web frameworks. The below list highlights a few interesting options outside of just the standard library. While more and more libraries are looking to support the evolving Python 3.x versions.

Nose

Pytest

Paver

Lettuce

Robot

Mock

PyLint

WebTest

DocTest

PyCallGraph

cProfile

Coverage

Jenkins Plugins

Requests

Stub Server

Pyshould

Pyvows

unittest

splinter

locust

sixpack

fuckit.py
tox
mockito-python

Python Testing Tools Taxonomy

Cascading

Cascading is an alternative approach to Hive and Pig for developers where processing of big data is done using workflow streams of map, filter, and reduce steps. The work is bounded within the ETL process using the metaphor of directed acyclic graphs for direct source to sink work streams. Also, the approach adds an abstraction over the explicit programmatic complexities of the underlining MapReduce job implementations. Cascading has a dependency on the Hadoop layer but also provides connectivity with a multitude of data sources. Hadoop can either be used as standalone or in a clustered environment. A developer can then work through an entire process stream in a singular or integrated workflow making abstractions in ETL for business domains very plausible and reduction in complexities of handling large amounts of data. The process streams can even be made available in visual representations. Cascading also provides various wrappers in form of Scalding, Cascalog, PyCascading, and others. The application platform is a nice alternative for developers looking to integrate and think through problems in business domain abstractions using entire feature and story cases of complex data processing through the test-driven and behavior-driven approaches within the agile practicing team.

Pair Programming

One of the lamest approaches to come out of software engineering in agile methodology is pair programming. It does not work on all occasions and is really a very unperceptive way to be productive in development. Most developers want a sense of autonomy, freedom, personal space, and exploratory approach to their development work. Not be constrained by process and by someone constantly over their shoulder feeding them nonsense. Pair programming can work when it is flexible within co-located desks. But, if two people are physically sitting next to each other it just becomes one really long and unproductive exercise. "Why do you want to do it this way why not that way" - if a senior developer keeps hearing that in their daily work day it is bound to drive them insane. Pair programming can work wonders on a complex piece of legacy code where there is virtually no tests and one needs to do a major service migration. In that respect, it means pairing with someone who either does know the legacy code or someone who can help in process of identifying problematic story cases. It may in that respect also lend towards productivity as one writes out a test case while another is doing the implementation or documentation. It may even help during training of a junior developer. But, really pair programming on a daily work day can be a very droning and frustrating process. For developers, that like to research and investigate new approaches as they go through their every day development, it does not really lend well to pair programming. One cannot test everything before deploying to production. There are always unknowns in a production environment for any number of things to go wrong. Agile approach is meant to work precisely for the reason of making a team agile - quickness, lightness, ease of movement, and nimble. Generally, a mixture of Lean and light weight Scrum use can work in that regard. It seems that many agile development environments have architects and managers that do not quite trust the abilities of their developers for which they start adding more pairing, excessive code reviews, and processes to make sure everything is checked over before it is delivered for deployment to production. Relying too much or adding way too many process-driven approaches into a development team defeats the whole objective of agility that pretty much manoeuvers a team back into the waterfall or seemingly unproductive iterative model. In summary, pair programming is an extreme practice which is not a necessity for teamwork nor for agile software development. In fact, it is most appropriate for those developers that require excessive amount of hand holding or the only way that they actually learn things in their line of work.

Dilbert Jokes on Extreme Programming

Indecipherable Requirements

These days in agile development teams there is more emphasis on design, implementation, testing towards delivery rather than the production of clear requirements. Requirements often times can become the stumbling block for either incorrect or slow implementation, as well as a complete misdirection in delivery. In agile principles communication is key between stakeholders and developers. However, such communication in requirements needs to be clearly written down and mapped out for clarity sake. Also, what is required needs to be translated into implementation. There is a translation step required here at point of functional and non-functional requirements. There are two critical points of communication failure in agile teams. One being between stakeholder and developers. And, another being between developers in the team. Often times the emphasis is on getting the correct information from stakeholders but not fully translating them between developers. These days the members of agile teams use various tools for such communication flows. In all fairness, development teams need to understand the fact that people cannot read their minds especially if such teams are working in distributed and co-located environments. And, without sufficient translation of clear requirements in written form it becomes very difficult for developers in the team who are tasked at implementation to manage and understand them. Furthermore, the speed with which the implementation is progressed can also suffer which impacts the delivery time scales.

Perhaps, a suggestion in such matters is to keep communication simple but clear. There should be no level of complications in the requirement translation and they should not read like a puzzle where the developer has to spend time trying to decipher what another lead developer or stakeholder has actually asked for in terms of implementation. In going forward there needs to be a set of work flow targets that are agreed between team members so the progress can be smooth allowing for less issues in communication and more clarity towards completed work. There are various ways in which such issues can be taken care of. However, it depends on the willingness of developers to allow for more clarity and understanding. Often times developers stress more on the technical aspects of their work rather than trying to improve their own effective communication skills.  In a lot of ways, BDD (Behavior Driven Development) improves upon such issues as it tries to relay more acceptance work from the get go of implementation and testing. In tools like JBehave, Cucumber, and Spock such approaches can further be integrated and automated with continuous integration tests. Even going further, the work flow can be outlined and mapped using agile tools. Additionally, elements of risk metrics and other methods can be incorporated in the process. JIRA is a very common project tracking application which comes integrated with other Atlassian tools. However, when a ticket is produced the actual verbiage that is added in as an issue or story needs to be defined clearly and synthetically. My proposed approach is to automate such requirements using specific keywords using a full work flow system where such issues and stories can be mapped and managed centrally with little effort. The specific keywords can be applied through script files and be modifiable based on team requirements of project work. For example, such keywords can be used in simple defined sentences: "for", "in", "out", "allow", "apply", "change", "remove", etc. All these words imply a specific task in relation to the work that needs to be applied. Notice the two sentence phrases below. The second one is clearer than the first in what really needs to be implemented and what really is implied from the stakeholder to the developer within a JIRA ticket.

• Filter out id that is not in the list of ids
• Filter for id that is in the list of ids

If one gave such requirements to a developer especially to a new starter, without any real knowledge of the system architecture other than the programming language, they may in fact get quite lost in terms of what was actually implied in the sentence. Moreover, if the written requirements do not agree with what the lead developer, architect, or stakeholder actually wants you to implement then that will increase the confusion not to mention frustration even more. Plus, relying on verbal communication to a limit is acceptable but may hinder the understanding even more as well as defeat the purpose of having formal requirements specifications as a way of tracking work and building automated acceptance tests. The first one reads with a double negative and almost like a puzzle. The second clearly states what needs to be implemented. Notice the keywords like: "for", "in", "out", "not", "list". These words make a big difference and not only that but the order in which they are put in the phrase can too. The first one implies to use for-each loop step to remove from a list. However, the second one implies for-each loop step to add into a list. The general terms like "out" can be translated to imply remove from and "in" to imply add in. But, obviously such keywords are based on context. Going further, if such keywords were added into a script file and the process of requirement production was automated it may in fact help speed up communication as well as correct implementation of requirements. If one is using JIRA this can be a fairly productive aspect for a team. Utilizing work flow modeling and Java, Groovy, or Python for integration and NLP for linguistic translation. The impediment from lack of requirements or indecipherable requirements could be reduced. The very same keywords can be linked to BDD acceptance testing criteria as well. When communication can be broken down into simple granular level with agreed use of words it can help developers understand and link requirements to implementations quite rapidly in an agile process. Requirements are an important step in the software engineering process. Such requirements need to be elicited, analyzed, specified, validated and verified in the process of delivery.

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.

Over Engineering Is Killing Creative Software

Is Agile good? Is it creating over emphasis on code quality and testing? Are they necessary evil or a balance needs to be struck somewhere? In a lot of teams TDD (Test Driven Development) and the transgression to BDD (Behavior Driven Development) has become a dominate way of development methodologies. But, are they really the only way? Should they really be what determines whether code meets the requirements? Shouldn't it be all about making sure you know your requirements and domain model first before you test? I feel pragmatism is really the best policy towards development. Agile approaches at times impinge on the flexibility that is so well required for creativity and innovation within applications development. Agile it seems has become a major factor in getting things out quickly where documentation is left behind and testing has become more of a factor. At times, the whole process just reeks in bugs. One can never be fully assured that no issues will arise once the code is released into production no matter how much unit, functional, integration, load, acceptance, continuous testing is done during the development, test, and stage phases. In continuous delivery perhaps one would not even require so many phases further reducing testing stage cycles but still inducing the risk of bug creep. As a person from a Computer Science background, I feel Software Engineering should not be what drives project development but what inspires better coding standards. In end, Software Engineering is a sub-field that empowers Computer Science providing the necessary skills towards developing in the large. However, in the ever changing landscape of the web and the increasing data processing requirements it is really the principles of Computer Science that pave the way towards extending and envisioning what could not be possible before. 

It feels digressing everything solely on grounds of methods-driven development expounded from Software Engineering makes the process a very uninteresting and tedious at times. People who study Computer Science by the very nature are interested in solving problems, finding algorithms that could do things better, or making solutions happen naturally that most people could not conceive of before. In process, Computer Science in all its endeavors allows one to build on the research of giants to further the potential of computers and systems as a whole. Software Engineering delivers processes, at times, more processes than is necessary and arching over Computer Science like a god father. There is a difference in the way a Software Engineer thinks about a problem and how a Software Developer thinks about a problem. There is also a difference in the way they go about finding a solution. The underlining difference arises from their background whether it be in Computer Science or Software Engineering. Through past experiences I have found that  at times, teams with a lot of people with Software Engineering backgrounds tend to focus more on processes whether they be testing, management, code release and what have you. Whereas, people in development teams coming from Computer Science background seem to approach the development from a holistic approach defined either by the optimization of an algorithm to pragmatic use of software tools. It is here where creativity is nourished and where innovation reeks interesting outcomes. Artificial Intelligence is a sub-field of Computer Science that over the years has become a major contributing factor to the Intelligent Web per se and to the derivation of information from the huge amount of data for which the term 'Big Data' has become synonymous.

I feel the way to go with development of projects is a pragmatic one. Keeping a balance on level of testing, project management, and the maintenance of code quality. Especially, against time pressures, many project teams can not support so much over engineering approaches to exist unless forced upon by architects at times. It seems only natural that people move further a field from Agile to more lean and second method phases beyond just the use of TDD or BDD. Flexibility is important and clearly from the development trend it can be seen that the old Waterfall cycle was a major contributing factor to movement away and towards developing better ways of approaching projects. However, one cannot always apply TDD to everything, and Agile at times has problems making sure teams maintain sufficient documentation. Also, developments too inclined to use Agile methods and tools end up leaving behind the customer in the process - pretty much losing the gist of what Agile was all about, test first and often, and deliver so the customer is always in the loop of work progress and acceptance. Open source frameworks and tools have allowed a lot flexibility for code reuse and rapid development of user cases in project delivery cycles. The trend is likely to emerge in more open source projects and support of such projects by industry. Even to factor in that so many open source frameworks and tools have only just been developed for development which makes it even more possible for teams to develop on time and check for correctness. And, above all else it has provided a way to reuse other peoples' code without reinventing the wheel of creativity - building better and productive code that matters. 

Agile in all its glory is a nice approach with a set of methods whether they be Scrum, TDD, or BDD are good to have in the mind set. However, use of them should be approached from what is the best way to go about a problem. Just like the use of design patterns, not all can be applied to all problems, all the time. Creativity and innovation is what makes even such methods and tools possible. So, killing the mind set with only accepting one way of doing something is like coming in the way of progress. Open source is all about freedom to create and collaborate. A balance in process-driven attrition and freedom to innovate, create and empower development is the best policy.