Summa

Many captive software development groups operate at low efficiency.  There are reasons, but do they justify shunning all process improvement?

Captive shops produce software with only one customer, the business side of the same company.  From an outside point of view, this should be a great situation for efficient software development, however the opposite is often true.  Why? Well, FUD.

Continue Reading Add comment

I know plenty of developers who, at a tactical level, have had success with static source code analysis tools, using them to help find and root out bad code smells. When PMD tells us there’s an empty catch block at line 207, for instance, we know exactly what to do.

At an aggregate level, however, code metrics are seldom so helpful or straight-forward. When seeing that a source tree has 160,000 lines of code or an average cyclomatic complexity of 4.12, our first thought is usually “interesting!”…followed shortly by “well, now what?”.

The problem is, in my experience, we often look at our code metrics in isolation, without good comparison points, leaving us to wonder whether the numbers we see are big or small, typical or abnormal, good or bad. In the end, it’s not clear what to do, if anything.

Continue Reading Add comment

As a newbie to the field of IT consulting, I am constantly observing my more seasoned colleagues. In my observation, a characteristic common among “good IT consultants” is that they are technology savvy. They are IT geeks and have a thirst to learn new technologies. They desire to be a part of the next big IT movement and spend their spare time - evenings, weekends, holidays acquainting themselves with new technologies, and creating mini projects to work on and learn.

Continue Reading Add comment

XML Schema Definition (XSD) files define the structure and data types used in XML messages. XML schemas are a must-have in any application that relies on the use of XML. XML Schemas have become the universal definition language for integrating systems, as well as for defining common formats used for data interchange. Although there is not a “one size fits all” standard for creating schemas, it is essential to define XML Schema standards within IT organizations in order to ensure XML schemas can be easily reused, maintained and extended while minimizing impact on existing integrations. Without best practices and naming conventions, a project can end up with inconsistent schemas that may be too rigid or too relaxed to meet project requirements. On this blog post, I will go over ten practical tips for designing and building reusable XML Schemas. These recommendations can be used as a starting point for defining XML Schema standards within your organization.

Continue Reading 2 comments

There has been much interesting debate over the different practices defining who is ultimately accountable for source code. Who creates and modifies the code? What practices best foster responsibility for its quality?

Code ownership practices are just one component in an organization’s development process. Some “famous-name” methodologies recommend or require a particular ownership practice. However, many organizations (for better and for worse) don’t strictly adhere to any one development methodology… This post makes recommendations to consider when incorporating any of the code ownership practices into your team’s code ownership “policy.”

Continue Reading 2 comments

When software developers and architects select open source software over commercial alternatives, there is often a premise that because the software is free, (as in beer vs. speech) there is zero cost associated with the choice. This post describes considerations and provides linked studies that provide help in clarifying how TCO may be used in the decision process.

Continue Reading 3 comments

So how do we manage this communication chasm? We all agree that having some software tools is good for the business. We all agree that there is a cost to develop custom software. But as we go deeper, we don’t understand much. The developers don’t understand the business domain and the business folks don’t understand the software domain. One way to look at this is by observing the growth in the number of details over the course of development.

Continue Reading 1 comment

In the early days of SOA many new products arrived on the scene that seemed to be solutions looking for a problem. As the SOA space matures (or maybe matured, since some have claimed it is dead*), so do the products and the relevant architectural patterns that use those products. However, there are other areas of SOA where you find solutions looking for a problem - the services themselves.

Continue Reading Add comment

When Voltaire wrote, “The perfect is the enemy of the good”, I strongly suspect that he did not have software design and development projects in mind. But he may well have in mind had one of problems that software development projects of often suffer: elegance creep. When is “good enough” actually better than perfect? What can architects, project managers and business stakeholders do to recognize and address elegance creep?

Continue Reading 1 comment

Summa is proud of our history of consistently delivering successful outcomes for our customers. Our reputation is built on being a trusted business partner that can be counted to “get it right the first time. “ Our track record of delivering success is illustrated by the fact that 90% of our customers have done repeat business with us. But this level of consistency and achievement does not just happen by itself, so how does Summa do it? There are three main factors that contribute to our strategy for success: having the right people, using the right technology, and utilizing the right methodologies.

Continue Reading Add comment

In most medium and large IT shops there are more people who can say “no” to a project than can say “yes” to it. From an IT governance perspective, it’s important to ensure that the only people who can obstruct a project are people who are authorized to do so.

Continue Reading 2 comments

A developer asked “How to convince someone [an IT manager] of the value proposition of great/beautiful code? (Or at least the value of code smell eradication.)”

This is a very real problem and is especially prevalent (in my experience) in larger, older programs that have met with some success, especially when the management are non-coder folk.

Beautiful Code is not an aesthetic pursuit; the Beauty lies in the fact that the code is well structured, concise, and obvious. This kind of beauty has high business value because it requires less effort and cost to extend with new features and to track down bugs.

Continue Reading 5 comments