Buying custom software design and development services, especially for the first time, can be scary. There is clearly a knowledge imbalance between you and your service provider. They (hopefully) understand the effort required to successfully build your product, and you don’t. This puts you at risk of being taken advantage of.
I understand this fear. Any time my car is in need of repairs, I am paranoid that the mechanic will take me for a ride. Other than being able to drive a car, I know very little about them. There is a clear imbalance between my and the mechanic’s understanding of labor and parts costs. This puts me at risk. Read more on Why You Should Trust your Software Vendor – From a Guy who Fears the Mechanic…
Most developers have been beaten down by time-to-market pressures in developing new products, from time-to-time. And some more than others… depending on the culture, maturity, and size of the organizations they operate within.
As time wears on in these tough situations, morale takes a nose-dive and bitching ensues as a way to cope. Digging yourself — and especially the team as a whole — out or these ruts is a difficult undertaking. Deep ruts are almost never caused by a single factor, and as a result, can’t be overcome by a single magic solution, nor in a short period of time. It takes patience, time, and persistence to get the train back on the tracks to allow the team to thrive once again, or maybe even for the first time.
But it can be done. Read more on Getting the Train Back on the Tracks – Turning Complaints into Solutions…
So, you’ve decided to rewrite your software. The entire team is ecstatic. No one will have to deal with the old, hard-to-use, painful-to-extend mess anymore.
Since you already have working legacy software, you have the perfect specification for the new product. Planning what to do should be easy right? Not exactly. Creating software from scratch is all about “what can be,” but rewriting software has to start with a clear understanding of “what is.” And your existing application probably does far more than you think.
Before you jump in with both feet, take time to do some research. The better your information, the better your software will serve your users, and the happier everyone will be at the end of the day. Read more on 2 Essentials of Planning a Software Rewrite…
I’ve been working in Visual Studio a lot lately, and I’ve found a few handy plugins that are very helpful for effective test writing. A good way to show these off is to follow my process for creating a new class and test via Test Driven Development. My goal here is to improve speed by removing the need for using the mouse (not to mention reduce the risk of repetitive strain injuries).
Here’s the short version:
|Navigate to a file in the test project
|Jump to Solution Explorer
|Create new test file
|Move class under test to matching folder in core project
|Vertical split between test and class
|Move files between split tabs
|Jump between files while editing
|Run the test
Now let’s take a look at the details. Read more on TDD a New Class in NUnit & Visual Studio without Ever Using the Mouse…
Congratulations. You and/or your company have a great idea for a software product, and you’ve decided to work with Atomic Object to build it.
At the beginning of the process, you’re likely feeling excited about your idea and eager to see things take shape. You may also feel a bit worried or daunted about the process of turning your initial concept into a real, functioning product. Whether it’s an iPhone app, a web-based product, a desktop application, or an embedded device, creating a piece of software is a daunting task that can span months, requiring many hours of labor and thousands of dollars. It’s important to get things started off right.
At Atomic, each project starts with a Project Kickoff session, which leads into a phase of Research, Discovery, & Planning (RDP). This phase of the project serves as a foundation for everything that happens afterwards. For me, this phase is one of the most interesting and exciting parts of working at Atomic, and in this post I’d like to share a bit more about the process and what to expect. Read more on Building the Right Thing – Define Your Product with a Kickoff & RDP Session…
If you’re reading this, you have probably ended up in a stranglehold of a mountain of seemingly-insurmountable “technical debt” at some point or another in your career. And you are probably also wondering if I have some magic recipe to extricate it from your future?!?
Or maybe you, like me, have, once again, run into the wall of resistance when you want to address a structural mess that’s makes everything you do more time-consuming than it should be. Maybe you inherited it? Maybe you wrote it? Maybe you have been building this house of cards for months — or even years — as you’re pressured into delivering features in less time than you really need to do them justice…
Whatever the backstory is, you’re in a slump, and “un-slumping yourself is not easily done.” (Thanks to Andy Brandt for identifying these categories.) Read more on Poor Structure and the Growing Burden of Tech Debt…
Developing an application and an API in parallel can be quite the tricky task. Often times, it can lead to misunderstandings and miscommunication between developers. This can cause a project’s progress to come to a screeching halt. The longer the misconceptions go unnoticed, the bigger the damage may be.
Read more on 3 Benefits of Fake APIs…
What does it mean to use an agile or waterfall approach to software development? What makes it different for the client? Where does it make the most impact for your project?
Read more on 3 Reasons I Choose Agile Design over Waterfall…
Documentation is a crucial part of any good API or framework. Despite this importance, it often gets neglected and treated as an afterthought.
I recently asked another developer how he always managed to put together such well-thought-out and complete documentation. His response was: “Documentation Driven Design (DDD): if your API feels clunky to document, it’s probably a bad design.” This reminded me of my first introduction to Test Driven Development (TDD). By breaking your code into smaller chunks and testing them first, you were immediately placed on a road traveling toward better design. Given how useful TDD has been for me, DDD seems worthwhile.
One of the main considerations that determines whether I use a framework is how complete and easy to understand the documentation is. But in my own hypocritical way, I’ve neglected good documentation principles on my own hobby projects and frameworks. Read more on Framework Docs Are a First-Class Citizen…
Recently I found myself faced with a new design challenge: to create a digital game interface that uses differentiating hardware and software components to facilitate a fun and social game play experience.
I looked for a framework to help me deconstruct the various aspects of the game into collaborative conversations I can have with client-side engineers, product managers, and marketers. I found the engineers were deeply involved in leveraging the hardware mechanics to design differentiating aspects of the game, while the marketing team was focused on product branding and visual design.
MDA Game Design Framework
I started as many designers do, weeding through the web to withdraw inspiration and artifacts to leverage something that might be pre-existing. That’s when I stumbled on the white paper “MDA: A Formal Approach to Game Design and Game Research” by Robin Hunicke, Marc LeBlanc, and Robert Zubek.
Read more on Using the MDA Framework as an Approach to Game Design…