Serenity of thought

Posted on Thu, 07/24/2014 - 13:42

Rands' recent blog post Busy is an Addiction struck a chord with me. It's made me rethink many aspects of my day-to-day routine. Work Smarter, Not Harder It's so easy to say, I'm busy. In reality, I should be working smarter, not harder. Busy is as much of a state of mind, as it is the items on your plate. It's a routine, a lifestyle, and a shitty excuse. If you fall into the busy pattern, I personally believe it's easier to make mistakes. Your pace is more frantic, your getting pulled in thirty different directions, and you really don't have the time needed to pay attention to what your doing

development drupal people

Open source tools are free

Posted on Mon, 07/21/2014 - 16:39

In a previous job, I had a boss that I really admired. He's near the end of his career and his experience had made him wise. He was humble, but would chime in as needed. One of my favorites was his ability to bust out short one-liners that would hit the nail on the head. Around the water cooler, we regularly discussed open source. Here are some highlights: Free like a puppy This one always made me chuckle. But, it's true in so many ways. I look at the open source community. At times, people's evaluations of open source tools are skin deep. "Ah, they are free!". This typically follows two

development drupal

Nodes with no page views

Posted on Wed, 07/16/2014 - 16:55

PrefaceNodes are the unquestioned most robust data structure within Drupal. It has widely adopted integration, e.g. Views, Features, Context, Rules, etc that make the Node a popular Drupal entity for countless use cases.However, the default node structure comes with a lot of baggage. It has built in publication states, authoring information, and revisions. Most of the time, these features are advantageous. Others, not so much. Nodes with no pagesDue to the robust features available for nodes, a content type is often created for nodes that do not actually have viewable pages. Let's look at a

development drupal

A balance of trust and quality

Posted on Tue, 07/08/2014 - 14:25

Projects are risky. Specifications are nearly impossible to define on most projects due to technical or communication gaps. This is the age old challenge many people fight. One popular solution for unclear specs is the fail fast methodology. It's founded on brief iterations that lack polish, frequent tests by a client and an over abundance of communication. This strategy is common for rapid prototyping and is effective for clients that can get their hands on something visually. All too often we fall into the trap of quality. Quality, to me, is only a metric of a final deliverable. It should

development people

It's not you, it's me

Posted on Tue, 06/17/2014 - 23:38

Bad projects are toxic. While most staff within a company focus on the bottom line, the bottom line is no guarantee of project success. It's impossible to look in your crystal ball and make this call before a project begins. Hindsight is 20/20, right? This could be due to any number of different factors. Some I have seen include: clashing personality between teams, a lack of participation on behalf of the client, unclear expectations of roles and responsibilities, client changes the requirements throughout the project, client cannot provide the clarity of the requirements, etc.When things

development people

An Agile Spree

Posted on Fri, 05/09/2014 - 12:20

At the heart of Agile is flexibility. This is designed into sprints that are intended to account for changes rolled into subsequent sprints.But, think of an overall backlog. A high level estimation will yield a given number of sprints. This structure actually is not very flexible at all. Unless, of course, each sprint has time allocated for reviewing, testing, and bug fixing. This is a slippery slope; a more substantial change can really throw off a sprint. So, how do you address the issue of quality?I have recently been reading a lot about corporations paying others to hunt bugs in their

development people

Risks and Unwavering Swagger

Posted on Fri, 05/02/2014 - 09:49

Push aside the user stories, contracts, and legalities. When push comes to shove, the developer delivers the goods. In my mind, there is huge risk to a project with the role of a developer. Let's be clear though. Every project has risks. Every project has some complexity behind it. What this means is that there is a dark art to the design decisions made by the developer. I've never seen a client accurately define what content types or modules need to be installed. Again, if they were that educated about what needed to be done, they wouldn't be paying you to do it. The developer must learn

development drupal people