• Faster time to market
• Higher quality products
• Products that resonate better with users

And though all of these can be achieved with improvements to software development processes, they rarely seem to get done.

One recurring reason for not achieving these is the absence, in many software organizations, of a dedicated SQA (Software Quality Assurance) employee or department. Too often, management loosely assigns the responsibility to an already-overworked employee, which guarantees that SQA will crash and burn.

It’s too bad that SQA is given such mediocre attention, because it’s often the key factor in achieving better products that release faster.

Do you agree? Is SQA often the secret to better products?

-Judi

Some of their common questions are

• Should developers interact with users? (Yes)
• Can developers write their own requirements? (Sometimes)
• Can developers test their own code? (No!)

I believe strongly in the last question’s answer. There needs to be someone else besides the developer to test the product.

Yes, developers need to test code to make sure it’s working, but the test team has a completely different mentality and skill set. They should be trying to see where the software breaks, because if they don’t find those spots, a user will.

Who tests your code? Are they doing a good job at it? Let me know.

-Judi

My primary embedded design goal is to make the man-machine interaction simple and intuitive. And today, more than ever, technologies are available that enable the creation of rich yet user-friendly experiences.

I recorded this video to introduce some topics I keep in mind when embarking on a new embedded design:

• Important factors to consider

• Technology alternatives

• User involvement

Let me know what you think. Thanks.

-Gary

One of the tenets of many mainstream software development processes is proactively managing risk.

Of course this sounds like a good idea, but the question becomes: how do you do it?

I’ve learned that addressing the riskiest areas in a project first usually creates the biggest returns. This is difficult, however, because most people gravitate to the easy things first.

The problem with going with our natural tendencies is that we can tackle a lot of easy things without actually accomplishing anything of significance. And if the risky thing doesn’t work out as planned we may have to throw away some of the prior work, which is always a major frustration.

I’m curious how my readers manage risk in a software development process. Let me know!

-Judi

The incredible throughput rates of GPUs allows for computation that standard multi-core Central Processing Units cannot provide. 

Companies are also beginning to add application processing to the GPU, known as GPGPU (General-Purpose Graphics Processing Unit). This is not a hardware device as such but is software and hardware working in concert on a GPU.

Since GPUs are not oriented to traditional application programming, various software platforms have evolved. OpenCL is supported by an industry consortium, KhronosGroup.org to promote platform independence.

The competing standard is CUDA which was created and is promoted by NVIDA, a leader in the GPU market.  Some say NVIDIA’s  GeForce256 was the first GPU. (At least it was marketed that way.)

Anyway, I’m interested to hear what GPUs my readers are currently using, and if they have any comments on their usefulness or shortcomings. Let me know.

-Gary

I just finished this video explaining the most critical aspects of implementing a software development process.

It’s an issue that I’m fanatical about, especially because it involves basic software development process strategies that can save companies tons of money and time. (And who doesn’t love extra money and time?)

Anyway, the video is 4:23 long, and introduces the below topics.

• Requirements

• Design

• Testing

• Source Control

-Judi

Gary Felberbaum, the Principal of Advanced Decisions, talks about testing real time embedded systems.

How early should someone consider testing?

The earlier that someone gets involved in setting up the strategy and setting up the architecture to enable testing is really important. You should to start thinking about how you will test an embedded system as soon as you are conceiving a project or an embedded system.

What is needed to get started?

The same steps are needed when starting to test or develop an embedded system. The starting process refers back to the simplest thing which is requirements: sitting down, defining what it is that you want to build, and then thinking about how to test the system (adding special electronics, special software, etc.).

Why is embedded system testing different from other software application testing?

It is different because you are interacting with a lot more real-world, physical processes. You’re measuring things that you may not have control over, while in application testing you can set up a test database and test against the test database. In the real world, for applications you have to think about how you’re going to simulate processes that you can’t control and that may take designing certain types of computer model and simulations that you need to do to make embedding system testing actually work.

The diversity of the companies is amazing: from online travel service Priceline.com, to oil-drilling equipment manufacturer APS Technology, Inc, to vaccine maker Protein Sciences Corporation, to IT Services provider OpenSky, the overall winner with 18,221% growth!

One thing I can’t help but ask myself is: what makes some companies so successful while others struggle? Listening to the speeches of each category’s winner, there was one common answer – the team. I’ve always believed that a small, talented, focused team can accomplish amazing things, and these CEOs were saying the same thing.

Congratulations to this year’s Tech Top 40, and to all those who aspire to join them – my best advice – surround yourself with the best and brightest you can find.

Building custom software is an investment, and that investment usually doesn’t make sense unless you’re going to sell multiple copies of the software, or it’s going to give you a significant competitive advantage in your business. And I do mean significant.

For example, I spoke with a company not too long ago that was thinking about developing some software to help them with an internal business process. They had done their research, and there were packages on the market, but they didn’t exactly meet their needs. I spent enough time with them to give them a ball park quote, and it turns out the custom solution was seven times more expensive than the off-the-shelf solution. Frankly, this isn’t even a lot. Think about it – if the vender of the generic solution spent the same amount of money developing their solution, they would only need to sell seven copies to break even. I realize it’s more complicated than this, there’s distribution, support, marketing, overhead, etc. but what if they sold 70 copies? You can see how this kind of investment could pay off. And if they sold 700 – wow!

So this company decided to buy the off-the-shelf product that met most of their needs. In my opinion, that was the right decision. It only makes sense to build custom software for internal use when you can get a significant competitive advantage. Before you think about investing in custom software, look at what’s already on the market to meet your needs. It may not meet all of your needs, or meet them perfectly, but ask yourself how much would it be worth to have that perfect solution? Would I be willing to pay ten times the cost of this package? More? Often the answer will be no, and in that case, just find the product that meets your needs the best or allows you some ability to customize.