In this class we have talked about the process of building software many times, but we never really looked into how much this software might cost to create and some different factors that would make a difference in it. I personally found this part of coding the one I kept wondering about so I found a blog post by Kacper Rafalski to learn more about it since if we are spending so much time on the creation of software it would be useful to know all the different aspects of its pricing including project size, complexity, team composition, and technology choices. 

First he explains the cost depending on the software type. The cost of software development depends a lot on the type of software being built. If the project is based on web development it can range from affordable prices to more expensive ones, while if you are creating a mobile app it becomes way more complicated and costs a lot more due to problems that arise where you need to support multiple operating systems for multiple types of phones. Meanwhile custom software development, which involves creating different solutions depending on the case, also varies in price based on the features required to create it and specialized fields like cloud computing and embedded systems are often very flexible and seen as better, but often makes the program cost much more expensive since it is a lot more complex than the other systems. He then explains that a project’s size including its features makes a big impact on its size, but also it has a lot to do with the diversity of its functions. A small company that wants a basic software might have to pay $100,000 meanwhile a bigger company that wants a more complex software will get a starting range of around $600,000. Pricing also depends on the developers. Developers that have much more experience will require much higher rates due to them being much quicker at working as well as being able to handle much more complex projects. There are also some hidden costs like maintenance that will be charged and system integration. The post talks about common pricing models in software development, like the Fixed Price, Time-and-Materials, and Dedicated Team models. Each model has its advantages and is suited for different project types and client needs. Overall the post recommends carefully planning your projects to budget well using different strategies to remain cost effective. 

Overall I believe that I learned a lot from this post and from now on I plan on approaching different projects with a more realistic and cost effective approach. I also learned that creating projects isn’t just about how well you can code, but also about planning strategically and managing my resources and budget as well as I can in order to be a better team player.

Link: https://www.netguru.com/blog/software-development-cost

From the blog CS@Worcester – Thanas' CS Blog by tlara1f9a6bfb54 and used with permission of the author. All other rights reserved by the author.

Role of Software Licenses in Protecting Your Code

Software licenses are essential tools for developers, companies, and organizations that create digital products. These licenses set the boundaries under which software can be used, edited, or shared, ensuring that the rights and responsibilities of creators and users are clearly outlined. By setting these boundaries, software licenses protect intellectual property, foster trust, and encourage innovation. They encourage more people to want to put out their work into the world for it to be utilized by everyone. Whether you’re an independent developer or part of a large organization, understanding and implementing the right license can make or break the success of your software.

Licenses are not just legal jargon—they’re critical to the security and success of your software. Without a license, your work may be misused, copied without acknowledgment, or exploited without your consent. By clearly defining permissions and restrictions, licenses empower creators to protect their investments while allowing others to contribute in ways that respect the owners’ visions for their software.

Real-World Example: SatixFy’s Landmark Licensing Agreement with MDA Space

link: https://news.satnews.com/2024/10/23/satixfy-signs-million-software-development-license-agreement-with-mda-space/

On October 23, 2024, SatixFy, a leader in satellite communication technology, announced a multi-million-dollar software development license agreement with MDA Space. This deal grants MDA Space access to SatixFy’s advanced software solutions for use in their satellite systems, setting the stage for groundbreaking collaboration. The agreement reflects the importance of licensing in facilitating partnerships that push technological boundaries, especially in fields as innovative and demanding as space exploration. This encourages new discoveries and developments to be made in space exploration showing the impact that this license can have.

The SatixFy-MDA agreement exemplifies how software licenses can drive collaboration and innovation. By granting controlled access to its proprietary software, SatixFy ensures its intellectual property is protected while enabling MDA Space to use cutting-edge solutions to make out-of-this-world collaborations. This approach benefits both parties, fostering trust and creating opportunities to develop next-generation satellite systems. Licensing agreements like this pave the way for advancements that could redefine how we approach space communication and exploration.

The success of software can a lot of the times solely depend on how it’s licensed. A well-chosen license can protect against people using the product and possibly distributing it while misconstruing the purpose of it and at the same time enabling growth and fostering trust among users and collaborators. Open-source licenses may help establish a community around your software, while proprietary licenses can ensure you retain control over commercial applications. On the other hand, poor or unclear licensing can lead to legal disputes, misuse, or a loss of control over your work. Overall, licenses are a big help in allowing software to succeed as well as setting the path for further innovation and collaboration.

From the blog CS@Worcester – coding.upcoming by Simran Kaur and used with permission of the author. All other rights reserved by the author.

To really boost your understanding, it’s better to dive into academic computer science papers instead of just watching tutorial videos. This approach helps build a solid foundation and explore future trends in the field. The article shares the journey of the “Papers We Love” team—Zeeshan Lakhani, Darren Newton, and David Ashby—who, even without formal training in computer science, explored key papers to expand their knowledge. Their experience shows how academic papers can shed light on the development of programming ideas and spark new ways to tackle problems.

The blog also recommends four key papers for anyone curious about computer science research, such as:

• “Communicating Sequential Processes” by Tony Hoare
• “Dynamo: Amazon’s Highly Available Key-value Store”
• “A Unified Theory of Garbage Collection”
• “Out of the Tar Pit”

Getting into literature can really help programmers grasp the theory behind their tools and methods, which can lead to smarter and more efficient software development.

I picked this blog because I think computer science is more than just watching tutorial videos. A lot of folks get stuck in “tutorial hell,” just binge-watching without really getting the deep understanding they need. This blog points out that diving into academic computer science papers can help break that cycle. By engaging with the core literature, you can expand your knowledge and discover insights that tutorials might miss. Checking out research papers allows programmers to really grasp concepts better and come up with more creative and informed solutions.

Reading academic papers in computer science is, in my view, an essential practice for individuals aiming to enhance their knowledge of the discipline. Such papers frequently lay the groundwork for subsequent innovations and offer perspectives that are not typically addressed in conventional resources or tutorials. Although the terminology may occasionally be complex, the endeavor to comprehend these documents is rewarding, as it cultivates a more thorough understanding of emerging technologies and theoretical progressions. By immersing themselves in academic literature, both developers and researchers can remain at the forefront of trends, improve their analytical abilities, and make significant contributions to the wider technology community.

Blog: https://stackoverflow.blog/2022/12/30/you-should-be-reading-academic-computer-science-papers/

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

Quick recap of the first post, Miriam Posner saw an Agile team working and as an outsider decided to research more about the process. The article started with the defining of programmers as software engineers, an attempt to add structure to the confusing new field. From there was the “waterfall” development process, a term coined as a joke that was picked up by the management and used until the inflexible nature nature caused one too many projects headaches. A new movement was made by 17 managers who wrote the “Agile Manifesto” in February 2001.

Picking up from there Miriam goes into a little more detail on “waterfall” shortcomings as developers see it, the largest of which appears to be that any slowdown was seen as a ‘deviation from management’s careful plan’ because software development was inherently stable, at least from management’s pov. Agile was supposed to be about removing long-term, higher level plans set in stone in favor of short-term, quick-paced goals that would give more flexibility for developers. Remove useless meetings about every little thing so developers can actually fix the problems at hand. Miriam notes that at this time there were few qualified devs, so they had all the power and could have asked for unions or complete IP ownership. Instead they asked for more efficient working conditions so they could do their jobs.

While this sentiment from coders culminated in the 2001 manifesto, according to the Agile consultants Planview it took until 2012-2015 for more than 50% of active development teams to characterize themselves as “Agile”. So that was it right, new mindset and all’s hunky-dory. Except it wasn’t.

In a cruel twist of fate, Miriam noticed a flaw in that Agile team that she had been watching be so efficient and intriguing. They didn’t seem to be getting much work done. What had happened was that due to throwing out the top-down approach to project management, no one on the coder’s side had a solid concept of the project in its completed form. They had thrown out the baby with the bath water. Add on to the fact that, while definitely anti-management Agile was in a way very pro-corporate. The entire mindset was let developers put their all into the project, which in turn is believed to have contributed to the recently seen burnout rate increases. On top of this is the issue that, due to Agile’s inherently non-structured nature as a mindset, there’s no one thing someone can point to to say “this is not good we need to change it.” Since nothing is actually defined in Agile, everything is subjective and thus at the whim of whatever the company decides.

From this article I have come to see that flexibility in my future work is necessary, don’t try to plan every part from day one. However it is equally important to try to start with a skeleton, something that I can add my features to so that I know both where my projects are at as well as what it can become. Hopefully this adjusted mindset will allow me to continue doing what I love for a long, long time.

Link:
https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Integrated Development Environment, commonly shorten as IDE, is something that exists among the modern Development Environment today. Imagine the common text editors software such as Notepad on Windows, or TextEdit on Mac, we can theoretically write the code and save it as the correct extension file, such as *.py, *.java, etc.. However, this requires us to learn every syntax of the code, as well as time consuming in terms of managing the working directory in the project. Therefore, the blog article “Understanding Modern Development Environments: A Complete Guide” by Matthew LeRay, will help us how to easily manage the development environment process in terms of the versatility.

In summary, the blog article gives us the basic introduction surrounding the definition of Development Environment. It is about comprehensive setup of hardware and software tools that software developers use to create and maintain software systems, along with other elements such as Developing, Testing, Staging, and Production Environments. The article highlights how IDE compared to traditional text editors process, which what we know today are syntax highlighting and code completion, and more highlights on the point of time consuming, enhancement of developer proficiency, and customization tools. And lastly, the article highlights the importance of development environment, where the goal is for enhancing developer productivity and ensuring high-quality software output.

I choose this blog article personally due to my own curiosity of “What if I try using a text editor software on my computer to write code?” The article did give a basic introduction in terms of the long evolution where IDE is formed from the traditional use of Text Editors. Reflecting on what I’ve learned using VS Code, it is not just basic functionality such as code completion and syntax highlighting, the versatility of IDE expands to the advanced features, such as integrated version control, and collaboration tools, in order to catch up with time management process as the complexity of the project grows over time. Overall, this blog article helps me learn that I can’t simply just rely on the text editors software, such as Notepad or TextEdit, as mentioned from the introduction of this blog post. And the reasons for why not can be seen as I started to get touch on the higher complicated project, where using an IDE such as VS Code would reduce the time process, as well as further advantages such as working with collaborations team, compared to solo development.

In my opinion, it’s easy get familiar with advanced, and modern Development Environments, where I think collaboration and time management could reduce the complexity of managing the project in the real world. Hence, trying to setup the crucial elements such as the right IDE, Version Control System, can be the good start when working with the modern Development Environment, to expand my versatility when working on with necessary tools to enhance the development proficiency, and for the overall production enhancement.

Blog Article: https://speedscale.com/blog/modern-development-environments/

From the blog CS@Worcester – Hello from Kiet by Kiet Vuong and used with permission of the author. All other rights reserved by the author.

This week, the blog that caught my attention was “How to Make Your Development Environment More Reliable” by Shlomi Ratsabbi and David Gang from the Lightricks Tech Blog. This work highlights common challenges encountered in software development and provides actionable solutions — specifically, how to optimize development environments. The insights offered in this blog align perfectly with our coursework, as we have continuously learned about and worked within our own development environments. This post emphasizes the importance of ensuring consistency and reliability when creating these environments, offering practical advice to achieve this goal.

The writers begin by outlining the necessity of development environments, describing the challenges that arise during software releases. These challenges include discrepancies between local and production configurations, mismatched data, permission conflicts, and system interaction issues. While creating a shared development environment may seem like the obvious solution, the authors point out that this approach introduces its own set of problems, such as debugging difficulties due to parallel testing, interruptions caused by developer collisions, and divergence between shared and production environments.

To address these challenges, the authors advocate for the implementation of branch environments. Branch environments are independent, isolated setups for developing and testing specific features or issues. These environments, when paired with tools like Terraform, Argo CD, and Helm, enable integration with Infrastructure as Code (IaC) and GitOps, automate infrastructure management, and ensure automatic cleanup of unused resources. This approach promotes consistent documentation of dependencies and application details within version control systems like GitHub. The blog includes a clear diagram and code snippets that effectively demonstrate how to set up branch environments using these tools, making it accessible and actionable for readers.

Branch environments offer several key advantages. By isolating changes, they ensure that all updates are properly tracked, simplifying debugging and maintaining consistency across development efforts. This isolation also eliminates conflicts inherent in shared environments, reducing the risk of outdated configurations or data interfering with new testing and development efforts. Tools like Terraform and Argo CD further enhance this process by automating repetitive tasks such as infrastructure provisioning and application deployment, saving developers time and reducing the likelihood of human error.

Additionally, branch environments improve resource efficiency. Since these environments are ephemeral, they are cleaned up automatically when no longer needed, freeing up valuable system resources and lowering costs. The inclusion of tools like Helm simplifies configuration management, even for complex architectures, ensuring a streamlined, manageable workflow.

Overall, this blog provides a thorough and practical framework for tackling one of the most common challenges in software development: creating reliable and consistent environments. The adoption of branch environments combined with IaC and GitOps principles enhances scalability, collaboration, and efficiency. As I continue to develop my own projects, I plan to incorporate these strategies and tools to build environments that are both robust and resource-efficient.

From the blog CS@Worcester by cameronbaron and used with permission of the author. All other rights reserved by the author.

Week-15: 12/21/2024

It’s easy to get something functional, but is it good? The book “Clean Code” by Robert C. Martin shows how my past coding techniques were wrong. This book isn’t just about making code work; it’s about crafting code that is understandable, maintainable, and, dare I say, beautiful.

The book highlights the importance of seeing code as a kind of communication rather than simply computer instructions. It’s about creating code that’s simple to understand, alter, and, ultimately, live with. The book provides several definitions of clean code, including the following: elegant, efficient, simple, straightforward, and carefully crafted. It also covers ideas and practices including utilizing meaningful names, constructing concise functions, correct commenting, formatting, error handling, unit testing, and so on. The book depicts the transition from sloppy to tidy code. It also includes a collection of code smells or heuristics that might help you write better code. 

I chose this book because I often find myself spending more time deciphering what code does than actually adding new features. I was looking for guidance on how to avoid creating such a mess and to understand what makes code easy to work with, and the book seemed highly relevant to my goals as a student. I also appreciated the idea that code is read far more often than it is written, so making it easy to read is very important.

This book has opened my eyes, particularly to the importance of code readability. It is not enough to have code that is functional; it must also be understandable to everybody who will work with it. This is particularly crucial in collaborative efforts. The author’s description of “code sense,” a carefully developed feeling of ‘cleanliness,’ struck a chord with me. Knowing that code should be clean isn’t enough; we also need to learn how to make it clean. 

I will be putting the principles of “Clean Code” into practice by always striving to leave the code cleaner than I found it. I also plan to be more diligent in naming variables and functions, keeping functions short and focused, and implementing tests to validate and describe code. This book has taught me that clean code is more than a nice-to-have; it is an important component of becoming a professional software developer. I now recognize that “working” code is only the first step; “good” code needs ongoing attention and effort. I’m excited to implement these concepts into my future projects, not just to improve my grades but also to gain more experience programming software.

Book: Clean Code: A Handbook of Agile Software Craftsmanship by Robert Cecil Martin

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

The planning process is an open source project is often created and monitored by the maintainers. This blog intends to go over the commonalities found by Safia Abdalla in open source planning mentioned in her article “Open source excursion: The poetry of planning”. I chose this topic because it relates to both the section in class where we went over licensing, which included open source licenses, and the section where we over different planning philosophies like scrum.

The first shared tendency between open source maintainers Abdalla lists planning with the intent to build excitement in the community that might hold many of your future contributors. Maximizing the outreach your plan gets among possible contributors and consistently providing updates when changes are made attracts attention towards your project, increases your chances of acquiring new contributors, and encourages existing contributors. Another common planning practice Abdalla lists is planning to prioritize. This planning method aims to optimize the process by which user requests and pull requests are fulfilled by distributing the responsibility among a chosen team. This allows for the efficient processing of requests, as well as allows many members of the team to get well acquainted with the user community and their hopes for the team’s project. The last 2 planning methods listed by Abdalla are planning to communicate and planning incrementally. Planning to communicate is a method of planning that, once a projects priorities and goals are well defined, aims to communicate those goals with the community. This leads to more exposure for the project, and possibly more support and contributions to it as well. Planning incrementally is a planning method where members of a team are mindful of the dynamic nature of the planning process, and communicate to the communities interested in the project the same thing, as to not mislead them.

Overall, these commonalities between open source planning all seem like good habits, and practices that would be useful for me to employ as a future open source project maintainer, and would also be useful as a contributor to open source projects to be aware of these tendencies so I can better align my work to the maintainers’ planning strategies. Planning with the intent to build excitement, along with being an effective planning strategy, sounds like it would also help for beginner developers to build a presence for themselves in the communities that are interested in the project that’s employing it.

https://increment.com/planning/open-source-planning/

Link to source blog:

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.