To Reuse Firmware or Not to Reuse

Sometimes on new embedded development projects I am presented the option of repurposing firmware that has already been developed for the intended platform.

At first glance, repurposing seems a no-brainer because of its potential for saving time and effort, but a closer look at the risks involved paints a different picture.

Risks of repurposing firmware include unknown bugs, uncorrected known bugs, poor programming practices, and "fragile" software that becomes unstable after change. And sometimes even though the software is well-written it just doesn't achieve its intended purpose.

Here are some criteria I find helpful when evaluating if I can reuse a firmware code base:

• Documentation: Does it exist and is it current? (Specifically, I ask for design documentation and test procedures.)


• Understandability: Simply read through the source code. Does the style and format conform to your standards?


• Testability: Has the code been unit tested? Can you duplicate the results?


• Availability of original developer: Can you contact the programmer(s) should you run into problems?


• Version and source control: Is the software under active management and control?

Unfortunately I have not found a failproof system to make this decision. However if more than half of the above points are answered in the negative I choose to start from scratch.

 

The Value of a Startup Mentality in Large SW Companies

Many of the large companies I work with, and have worked for, are trying to figure out how to create an entrepreneurial culture in the fashion of today's successful startups. I think this is a fine idea, especially the modeling of two particularly attractive traits of startups.

1. Speed: They just get things done! There’s no long approval process, and sometimes there’s no approval at all. "Just do it" is the mantra. Of course, speed should never turn into carelessness, which can then turn into chaos.

2. Budget: I know one firm that has built one of the most innovative and technically challenging products I’ve seen in a long time using various open source products. In a big company, there’s often money to spend, and it gets spent, and often with much less successful results.

I’ve worked in both big and small companies, and there are advantages to each. The resources of a big company are nice, but for me, nothing beats the passion and resourcefulness of a startup.

-Judi

Software Design Considerations

In continuation of my content series on software development process I’ve added a video on software design. It talks about important aspects to consider and also issues about designing in an agile methodology.

You can watch it at http://www.youtube.com/watch?v=z5Xf3EO02E0

Also, I'll be recording some new videos soon. Feel free to suggest a topic you're interested in. Thanks!

Are Your Error Messages Understandable?

Even though we like to picture ourselves as flawless developers, it’s important to address how our systems will behave when users encounter an error.

I usually break the possible system responses into 3 categories:

1. Bad: The system throws the user out, and potentially deletes the user’s unsaved work.

2. Slightly Better: The system doesn’t throw the user out or lose their work, but brings up a cryptic message in programmer-ese that just confuses the user.

3. Best: The system brings up an error message that’s understandable and informative, and also provides advice on how to avoid or fix the error.

If you hadn’t already guessed, I recommend the third option. However, this is also the most difficult to properly configure, because each system error must be linked to a plain-English explanation.

Emily Wilksa, a former technical writer for Microsoft, has written a helpful article on writing effective error messages. Click here to read it: http://www.writersua.com/articles/message/index.html

-Judi

 

Embrace Change

I’m amazed how many developers and companies are reluctant to adopt modern technologies in their projects, especially when it could cut significant costs from the development process.

I even recently met a team who is still designing serial communication ports for their external interface. Ouch.

Thus, I'll focus my next few emails on development technology areas that have significantly benefited from recent innovations:
• Display technologies: highly integrated graphic chips and capacitive screens
• Wireless communications: near field communication, Bluetooth, WiFi
• Location-based systems: low-cost integrated GPS chips

-Gary

Testing Real Time Embedded Systems

 

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.

Build or Buy? How to know if you need custom software

I met a woman yesterday who asked me if we could build some software for her business. I told her yes, we could, but it probably wouldn’t make sense. Let me explain.

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.

Want to develop a new product? Where do you start?

I’ve been working with a lot of companies lately that have never developed a new product from scratch. They all seem to have the same question – “Where do I start?”

The answer is always the same – with requirements, and by requirements I don’t mean a bullet list of features, although that’s a start. By requirements, I mean detailed requirements of what you want the product to do and how it should behave in every situation. Error conditions are one thing that’s typically forgotten. Requirements are also not necessarily functional, for example, the maximum (or target) manufacturing cost is a common, and commonly overlooked, requirement for an embedded system. They say the “devil’s in the details.” In this case, that’s true.

The first question clients have (well, maybe it’s not the first, but it’s the big one everyone wants to know) is “how much will this cost?” Without the kind of detailed requirements I’m talking about, it’s impossible to give any kind of meaningful estimate. That’s why we’ve had such great success creating an initial engagement that delivers requirements and a rough estimate of time and cost. This initial engagement typically lasts between a week and a month, depending on the scope and complexity of the project and gives the client accurate information that they can use to make decisions. We usually find areas of trade-off, like features that could be in a future release, and can balance the client’s time to market and budget needs.

So remember, next time you have a new product you’re developing. Details, details, details!

The Art of Requirements Writing

The one area where I see companies could improve and make a HUGE impact on their development is in Requirements Writing. Most companies err on the side of too little or, unfortunately, way to often, none.

The biggest problem we see as a result of insufficient requirements is almost always scope creep, meaning that because there is no baseline, features just keep getting added to a release, and the result often is that the release never gets released. The other common problem we see from non-existent or insufficient requirements is that what gets implemented is often not what was intended, and if by chance the implementation is done correctly, it has taken a lot more work, time, and interaction than it would have otherwise.

The other side of the coin is perhaps more interesting. It’s rare, but sometimes we see companies that put too much in their requirements. I think this fear is why some companies don’t do anything at all – they don’t want to spend eons writing reams of paper and analyzing every detail. Rightly so, it’s a waste of time. The kinds of things we see in this area fall into two main categories of content and formatting.

As far as content, the biggest error is trying to turn a Requirements spec into a Design spec, meaning that instead of detailing what needs to be done, the requirement details how it should be done. Now there is a place for this, but it’s not in requirements. Specifying the how in requirements really limits the options and almost always results in a sub-optimal design. If the requirements are being written by a business analyst, as good as they are, they are not usually experienced architects or developers. Even if they are being written by a developer, the benefit to separating what from how allows the developer to look at all the requirements as a whole and in a separate thought step design the how in the best way taking everything into account, not just one requirement.

As far as format, the least useful way to write requirements (and ironically, probably the most difficult way) is in paragraph or prose form. There’s just too much content, and the important points are not easily identified and digested. Additionally, it takes an additional step for every user of the requirements (development, QA, Tech writing) to get the relevant information out. Obviously Use Cases are a tried and true and very effective method, but even bullet points (as long as they contain enough information) are preferable. The information contained should include the user entries, the results, any exception or error conditions and any other affects of the feature, easily and quickly captured in a bullet point format without any extra text to wade through.

Bottom line – well written requirements are HUGELY helpful to everyone in the development process and will make a great impact on getting your product out quickly. I’m sure there are offenses I’ve missed here. What other kinds of things have people seen??

Making the same mistakes

I hear it over and over again from technology execs – I know we should spend the time writing specs or working on our process or on architecture or designing a good UI or testing or documenting or - fill in the blank.

Yet, time and time again, I see companies making the same mistakes. It kills me! I asked myself “why do they do it?” After all, it’s so easy to improve your delivery time and quality a little bit at a time. I know it’s hard to find a place to start, but for some companies I see, anything would help them. When in doubt, remember that good requirements make everything else easier!

Then I remembered something I’ve heard repeatedly “The pain of the change must be less than the pain of the status quo”. I get that change is tough, but some of these changes (i.e. good requirements definition) are not that painful. I think a more accurate assessment would be “The fear of the unknown must be less than the pain of the status quo”

Do any of you have less than optimal practices in your product development? We all do, in one way or another. Things can always be better. Why do you stay where you are?

Driving Students to Tech Careers

I recently read an interesting interview with three senior executives at Google. The article was about women in technology, but one of their points intrigued me. They hypothesized that the prevalence of technology in our lives (smart phones, Facebook, etc.) will drive more young people to technology careers. They will use it and some will be curious about how you create a smart phone or an application like Facebook.

This sounds likely to me. Recently, I was speaking to a group of girls and shared that I had no idea what Engineering was when I went into college. All I knew was that it used math and science and I could get a good job when I was done. That was enough for me at the time. Fortunately, I enjoyed the intellectual challenge of solving problems and the satisfaction of creating something from scratch.

Now a days, when I describe what Advanced Decisions does, I have plenty of commonly known examples to point to. My typical “definition” of embedded systems programming is “writing software for an electronic device like your phone or your car, or your microwave, or medical equipment.” People usually understand that.

Do you think the prevalence of technology in our lives will generate interest in careers in tech? If not that, then what might? One of the points the women made in this article was that it’s not really about just women in tech. We have a shortage of programmers and engineers and need more regardless of gender.

A sad yet preventable story of software failure

I read an article today reporting that Nokia had announced that it was abandoning its development of its own Smartphone platforms and APIs. By itself, that’s not so sad. It’s smart to know when to cut your losses, right? The reason this story makes me sad, is that it was entirely preventable.
According to reports from insider Mark Wilcox, “there was no proper requirement spec for this new framework.” Aggghhhh! This makes me crazy every time I see it, and I see it a lot.
Companies think they can save time, or they don’t want to be “locked in” or say, “We’ll just tell the developers what to build.” In 20+ years of personal experience, I’ve never seen this work well. In the very best cases, tons of time is actually wasted by long meetings, miscommunications, and do-overs. Usually the end result is not really what the project sponsor wanted, but they settle. In the very worst cases, like this one, companies spend 2000+ man-years (yes, you read that right) developing something no one wants! In this case, they had two competing teams (I’ll have to address that in another post – just too much to say on that one!) and according to Wilcox "both teams had built the wrong thing.” Both teams! (This post may be my personal record in use of exclamation points.)
Another comment he makes is that “the engineers were incompetent. Now by that I don't mean that they're incompetent engineers – far from it. They were incompetent at designing APIs for 3rd party developers (a very specialist engineering skill) and they were incompetent at designing UIs (which most engineers are, myself included). Unfortunately they were doing both.” These could have been very bright engineers, but as Clint Eastwood said in one of my favorite Dirty Harry Movies, “A man’s got to know his limitations.” This also happens frequently and is an error made both by engineers (ego, desire to learn, fearing for their job security) and management (don’t want to hire specialists, over estimating their engineers). Again, in the best cases I’ve seen, the engineers can muddle thru and get something passable. On the other hand, it can be a train wreck as in this case.
The aspect that makes me the most upset about this story is the effect on all those engineers. They worked hard, I’m sure long hours at times, to develop basically, nothing. We engineers develop software and products because we take pride in our work and want to build things that people love to use and these engineers spent years not doing that. I can’t even imagine how unfulfilling that was.

Watson on Jeopardy

Did you see Watson, the IBM computer compete on Jeopardy last week. I did, in fact I was really looking forward to it. Obviously the geek in me was awed by the computing power.

Watson clearly dominated. In the three day match he beat the two human competitors by a margin of roughly 3 to 1. Obviously Watson got many answers right, but what I found interesting was what he got wrong. When he was wrong, he was VERY wrong! I’m sure we’ve all heard about the Final Jeopardy answer in the second match. All those people from Toronto never knew they were Americans! But some other more interesting mistakes where when he didn’t even give the right kind of reply.

For example, on the question: “In May 2010 5 Paintings worth $125 Million by Braque, Matisse & 3 others left Paris’ museum of this art period?” The answer was Modern Art, Watson said Picasso, obviously not an art period.

The use for this kind of computing power boggles my mind. We just have to remember to sanity check his answers!

Software Process Improvement Consulting

In 2005, I joined Advanced Decisions to establish a Software Process Improvement practice within the company. Well, long story short, I got busy with our core business of software and hardware product development and we never formally developed that practice. The interesting thing is that we seem to provide consulting on Software Process and SDLC as part of many of our engagements anyway.

The most obvious example is our work with start-ups. We typically are engaged to develop their product, but often wind up developing their process, their team, and even on occasion aspects of their business. With our larger clients we develop good quality documentation that’s often used as an example of what to develop in the future. Even with our prospects, we ask them enough questions about how they are developing their products to get them thinking.

It just goes to show, the outcome of a goal or desire may not always look like you expect.

When you’re done with product development

….you’re not really done. Let me explain what I mean.

We meet with lots of people and companies that would like us to develop products for and with them. They are sometimes under the impression that when we’re done creating the product, they won’t need any technical, engineering, or software development. After all, that phase is done, right? Well, yes, but the next phase is just beginning, and faltering here can be deadly to your product’s success.

Even if your product works perfectly, customers are going to have questions. Some sort of support will be needed. Not planning for this can be fatal to your product’s success. Often times, customers will be highly engaged and wanting more features and add-ons, creating opportunities and the need for enhancements. Ideally, more customers will want your product – maybe from an adjacent market or with needs not exactly targeted by your product, perhaps creating a need for other products.

All of these scenarios require additional support and/or continued development. Hopefully your product will be so successful, you’ll never be done!

Qualities of Top Developers

We’ve often heard about the two fold (or five fold or ten fold) productivity increase between the top developer and the average developer. I’m sure we’ve often (ok, always) wished for a team full of these folks, but somehow we rarely get that. We tell ourselves that top developers are hard to find, they’re one-in-a-million, or that it’s just luck to hire them. There may be some truth to that, but there are certain characteristics that software experts share, and if you recognize these characteristics, you are more likely to either find them or cultivate them on your team.

First, and most obviously, top developers are among the most technically competent on your team. The have a wealth of tools in their toolbox, and the ability to use the right one for the right job. Both the breadth and the depth of their expertise are usually built over time and a variety of project challenges.

In addition to skills and experience, the best technicians tend to have great natural ability. Their brains just work in a way that makes designing programs easy. This has enabled them to build up their toolbox by allowing them to learn tools and techniques easily, and determine which ones are valuable and which are not.

A third characteristic is attention to detail. Whether it is in the requirements, design, coding, or testing phase, attention to detail will help ensure the work product is high quality. In their own personal growth, attention to detail is also important as it helps them develop new techniques and avoid old mistakes.

Fourth is the desire for continuous learning. Top software professionals are always “sharpening the saw”. They are learning new languages, processes, tools, or just simple techniques to build more good code faster. They are always up on the latest trends and eager to work with new technologies.

A final characteristic that is found in many of the most effective developers is teamwork. In most companies these days, interpersonal relationship building is a necessary skill. Most developers are not people oriented to start with, and those that can develop this essential skill have a huge benefit over those that do not.

Every top developer may not have all of these qualities, but be assured that they have most. Screening for, interviewing for, selecting, and nurturing these qualities will go a long way towards improving the effectiveness of your teams and your software development efforts.

The Life of a Consultant

I had lunch today with one of the smartest people I know (no, I didn’t have lunch alone!).

He’s a software architect for a large global financial services firm and has found himself with an interesting job – he’s the “go to” guy for all of their most difficult software challenges. He referred to these projects as simultaneously repulsive and fascinating. He and his small team of equally brilliant people move from project to project – usually the ones that no one else want to take on, and unsurprisingly (to me at least) they are successful at solving these seemingly impossible problems.

The thing I found most interesting, is that the things he likes about his job are exactly what our consultants like about consulting: New challenges all the time; staying up to date on cutting edge technologies; and focusing on new design as opposed to maintenance.

I know this kind of group, (architecture, special projects, internal professional services, etc) exists within many big companies. This could be an alternative for engineers and programmers that crave the challenges and variety of the consulting life. Anyone have any experiences working in this kind of a group? What do you think?

Keys to a Successful Development Project

I was reading an article about startups recently and the author claimed that success was not due to one big thing, but a lot of little things. We had a business coach a few years back that said the same thing – when we reach the level of success we’re aiming for we won’t be able to look back and put our finger on one thing, but instead, we’ll see it was many little things contributing and working together.

It got me thinking – is that true of software projects as well? Probably. This may be one of those universal laws like the Pareto principal (aka the 80-20 rule), that seems to apply to everything.

Is there one thing, one big key that will make a project successful? If I had to pick only one, I would say it would be the team, but is that enough? I don’t think so. Even the greatest team can’t be successful with a lousy idea, bad requirements or no funding. Sure they may be able to get something out the door, but will it sell in the marketplace? Will it really meet a need? Probably not.

Ok, so I guess we’ve established that I don’t believe in “silver bullets”. So back to the original premise – what are all those little things? Well certainly the team, but what about tools, processes, appropriate budgets, management support, a great idea, customer need, stellar marketing, support, sales, etc……

It really does take a village!

Feast or Famine in Software Development Organizations?

In so many areas of my life I go thru these cycles of feast or famine – social engagements, work load, car problems, what have you. I either have lots or none, or is that just my perception?

There’s one area that I can think of in which I’ve never had this problem – the software development organizations I’ve been a part of. Sure, we’ve had that with bugs, or turnover, but never, ever, ever workload. There was ALWAYS more than enough work to do. Maybe it’s just the nature of the beast – companies always want to improve their products and there are a wealth of ideas on how to do that. It’s also a positive thing. I love being busy, and if a company can not keep it’s developers busy, why does it need them?

The downside however can be a feeling of overwhelm, or inefficiencies, or continual long, long weeks. What kinds of things can we do to smooth this out a bit, or at least mitigate the negatives? I have some ideas:

1) Prioritization – so many organizations are SO bad at this. The priority is the priority of the moment, based on the loudest customer, one data point, or the whim of an executive. A well thought out prioritization can allow your development teams to get more done, just by finishing what they’re already working on. I’m not saying it should never change, but it certainly should change less frequently than you change your clothes.
2) Focus – knowing the big picture will help with number 1, as well as with coherency of design and team morale. If you’re building something to do x, don’t try to do y. Pick one thing (at least to start) and do it exceptionally well
3) Learn to say “No” – I find that people (not just in development organizations) spend an inordinate amount of time exploring roads not taken, as in “maybe we should have done x”. I once heard a speaker call this “Killing the un-chosen alternative.” I like that, and not because I’m violent – I’m not. I like it because it allows you to devote 110% of your attention to being successful on the path chosen and stop second-guessing yourself, a time wasting distraction if there ever was one.

I for one hope there isn’t a famine of new product ideas or developers to carry them out. Let’s just try to do it sanely.

Hiring engineers now is easy, right?

Wrong!  I’ve run across quite a few people in the past year that have assumed that’s the case, but have found out differently.  Hiring top software programmers and hardware engineers is always a challenge.  Having piles and piles and piles of resumes does NOT make it any easier.

So what’s a hiring manager to do?  Well, the last hire I did for myself (as opposed to the ones that I help our clients with) I had four very clear objective criteria.

1)      The candidate had to have a Bachelors’ degree

2)      The candidate had to have experience with a specific program

3)      The candidate had to have at least 2 years professional experience

4)      The candidate did not require H1-b sponsorship

One of our clients is doing this now with good success.

Now, I know you can make valid arguments against any of those hard and fast rules.  Some of the smartest people I know don’t have college degrees.  In different times I might have made that argument myself (might be good idea for a blog entry next year), but you need some way to get through hundreds of resumes a week.  The nice thing about objective criteria is that a hiring manager can get help – someone to prescreen for him.  So what are your deal breakers?  Knowing that going in will make hiring in these times much easier.

I’m sure all you job seekers out there are saying “That’s not fair!”  You’re right, but as my mother always said, Life’s not always fair.  So what’s a job seeker to do?  Well, I need something to write about next week…