Software Engineering process

There is a stunningly high number of otherwise responsible embedded designers (and managers) who just don't buy into best practices.

They're aided and abetted by dip-sh** bureaucrats who want to impose process for the sake of process, and come grinning out of the woodwork any time you try to implement process for the sake of product improvement and a sane work environment.

--
http://www.wescottdesign.com

Some are & some arent. One place I worked had one guy just about full time managing s/w documentation, processes etc.

Another place I worked with around 5 engineers, the embedded software guy fought tooth and nail against any form of process and documentation. I think a lot of guys figure lack of processes and documentation gives them somehwere to hide.

Op Thu, 11 Jun 2009 02:19:07 +0200 schreef dawydiuk :

Immature software teams (in terms of process) are quite common, even in large companies. The chaos will get worse as the product becomes more complex, until somebody important yells "stop!" At that point the company will start losing serious money while standards and processes are evaluated, unwilling engineers leave, managers get nervous and the deadline becomes a moving target.

I've seen it happen several times from the sideline. Some have fizzled out, some have made minimal improvements and some have successfully moved up to the first level of maturity.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

l

Coming from a background with rigorous control processes (>50% of my day is spent on non-engineering administrative tasks, even though my group has a person whose sole responsibility is to take an email from an engineer and turn it into an Agile workflow task), I can say that most of this sort of PDM software is overkill for a tiny organization unless you have a client that specifically requires it.

It is possible to reach at least CMMI level 3 without use of any special software beyond a RCS and, optionally, an issue tracker (though quite a bit of manual work is required, using the RCS to maintain the audit trail on everything).

I am one those people who think that all this talk about processes and metrics is simply BS. The whole term "software engineering" seems to have little to do with engineering - it's about project management and business models, and that's not engineering. It may work well for large companies employing *a lot* of programmers writing business applications or the like in *huge teams*, the main idea being to ensure people are expendable and enable outsourcing. One programmer quits, another one steps in and "starts coding". However, it's obvious from the poor quality of today's apps that this is not working. I believe most apps can be developed by small teams (

In a small company software engineers are usually way to busy to make time for this type of stuff. If it comes down to choosing survival and meeting deadlines over having a process that gives one a false sense of orderly work.

I am in nearly the same situation as the OP in my job. The lack of process can seriously negatively affect the deliverable quality of the final product both in terms of delivery deadline timeliness and product performance. And it's always only evident at the tail end of the effort without any process.

Process shouldn't be burdensome as several others have said. But it must work to be useful. A lack of process is a no-go in my book. And processes don't have to be formal. I suspect the respondent I partially quoted above thinks that's what process is: a formal recipe. Yet he describes his process. Sadly he left out formal SW testing which will always answer the question "Are we done yet?".

To the OP: You'll never be able to implement a broad and useful SW process without management support. That's because you can't do it alone so management will need to see the value of spending money to use it. What you can do is use your own personal process of good practices and metrics collection. Use the data to make a case to management that your process works. You'll also need to evangelize for SW process periodically. A repeated message will eventually be heard and maybe even acted upon.

JJS

So what do you say when someone loses the CD with the source code for the latest product, and the company goes bankrupt? "Oops", and "where's my resume"?

Don't say it doesn't happen -- I lost a good customer to that particular failure in process.

--
www.wescottdesign.com

the

I can count on the fingers of one snake the number of projects I've been given in a day job that have had a sufficiently detailed spec to be able to develop a test plan to begin SW testing.

If I did a single consultancy project as haphazardly as the way we work in my "regulated" workplace I would never see another side-job dollar again.

--- then forgotten as soon as top management changes.

Which is why I no longer have the stomach to work for 'the man'.

--
www.wescottdesign.com

That's one thing. What's even worse is when top management reads a magazine or uses the urinal next to a consultant with a pet method of doing things, and decides to reorganize the company. Functionalized groups. Project-based teams. End-item grouped teams. Individual consultants. Round and round the merry-go-round we go.

Well my post was intended to question the notion of using a "formal" process when developing embedded software - e.g. you do this first, that that, then that, all the while documenting in this manner and that and when specs change you do that and... The point was that every embedded project is (somewhat) unique and an (somewhat) unique process should be applied. And by "process" here I mean something that has nothing to do with management or the company's business model and everything to do with, well, design and development. So many would refer to this as "no process" or "chaos". IMO embedded systems design wouldn't work just by picking out a popular general-purpose process model (i.e. something out of some book) and forcing it upon a project.

As for SW testing, this concept is a BS generator in itself. When I hear "formal" in the context of testing I think about models, formal methods, model refinement etc. SW engineering folks, on the other hand, often think that the way to go is to blurt out some code and bang it into shape until it passes "unit tests". That kind of coding sounds like a big no-no for embedded systems. At least if you don't like unexplained crashes in the final product... The point being that the process itself doesn't help, you need good design and good embedded programmers. From my perspective, process, SW testing and reliability talk often seems to lead to BS in the form of heaps of non-technical documentation, six-sigma black belt consultants etc., actually leading you away from testing. Wouldn't you say that we need some common sense and someone who understands the problem well enough to design meaningful tests in the context of the whole system?

I'm looking forward to hearing other opinions to see whether there is some common agreement in this process talk (after transcending terminology issues :).

RG

Thanks for refining your argument. It does make some sense.

I take exception to the SW test BS remark. It needs to be done responsibly and effectively and not just a way to justify one's job. Your tester or SW QA guy should be your antogonistic partner (a good relationship) and not the guy in the other part of the building. I think you (and certainly I) haven't met a good embedded SW tester yet. It's a specialized skill just like embedded programming. Let's say you and I are good at what we do (embedded programming). It stands to reason there should be somewhere a SW QA who's equally skilled at testing our creations. By "testing" I mean thorough and meaningful testing including conformance to requirements; not "formal" testing which is the term I used before.

JJS

Interesting, you have the same opinion as a more senior engineer at my company... I agree software engineering is about project management and has nothing to do with the actual engineering.

In my opinion someone needs to manage the project, having a community of managers really doesn't work. And it's the managers responsibility to be familiar with software engineering best practices(e.g collecting project metrics, using version control software, having a software process). You would probably think something a simple as using a version control system is common sense, but it actually took several months before I could convince another engineer to check his code into a version control system.

I agree one hundred percent, although this assumes all of the engineers agree upon what common sense is. Personally I believe it is common sense to test code before you ship it or to check your source code into a version control system so you can track changes, but it is not common sense to some very productive engineers... After realizing what I would consider common sense others do not, is about the time I realized we needed a software engineering process. More than anything to get everyone on the same page and to remind engineers not to take shortcuts when we get busy and they feel pressure from management.

Wow, no bugs you must be good :)

In the embedded system area I'm familiar with, customers often want to upgrade existing systems we've designed for them. Or we use and existing design to implement a custom project. Returning to code years after it was written, or fixing bugs years after the system was developed is what I would call maintence in the embedded world.

I agree Software Engineering has nothing to do with the actual implementation(Engineering), but has to do with how you manage the project. If you know of a way to implement software where there are no bugs I think you could probably make a lot of money and I'd be interested to know your secret ;) I think metrics are very important to keep, it is basically creating a closed loop system. Without metrics what feedback do you have, in my opinion you are running an open loop system with no project metrics.

You seem to imply "engineers" are some elite form of "developers" as they require no management and apparently they also don't write code with bugs :)

What happens if you are an engineer, but your coworker is only a developer? In this case do you try to get a software engineering process in place? What happens when you are assigned to a project he worked on in the past because someone has reported a bug in his code(after all he is just a developer). When you ask him what changes he recently made he shrugs and says I don't remember. So you ask where to find his code in the version control software and he says he didn't check it in he only has the current version. Do you try to get a software process in place to manage him?

Regards, Eddie

Heh... You sure got me on the no bugs bit. :) I was trying to make a different point for embedded systems - there is no trade-off for

*intentionally* leaving small bugs open against time-to-market because this small bug could e.g. lead to a memory leak and crash the system. If you develop a business app in Java, the bugs are of a different sort and most of the app's functionality is not critical so you can choose to release a less stable app and create patches later, according to your process model (contrary to common sense). I was pointing this (and other things) out precisely to drive this discussion into details, whether we're talking about the usual abstract processes-to-be-followed-blindly-for-the-sake-of-processes management talk/pseudo-science or something useful. I'm interested in this topic (in my own special way) and this thread seems to be very informative.

The engineering vs. development bit was again to stress some crucial differences between embedded and general-purpose software. When doing embedded you often engineer the whole system, i.e. design HW, select the OS, port/write drivers and do the application itself. It's my opinion that all the team members should be familiar with the whole design (contrary to expendable "developers") so they can avoid making some obvious bugs which wouldn't show up until after integration. This should also enable better self-management of the team. And also, I meant that programming embedded systems should be more of an engineering endeavor in terms of design partitioning, hierarchy, testing, integration etc. For me engineering implies discipline and "development" doesn't. This does not necessarily imply that embedded engineers are better (more elite) programmers than general-purpose "developers", but this approach is more suited to the task.

As for common sense, I was wondering whether by "process" someone could simply mean "try to draw-up a high-quality specs document, let the whole team read it and discuss it 'till understanding and then use SVN and DoxyGen while developing"? I know people who would describe this as a lack of process and that's why I refer to it as "common sense" rather than a "process". :)

Cheers, RG

Just to make sure I was not misunderstood, I don't think SW testing is BS, but rather that is it a BS *generator*. SW testing and reliability issues have a tendency of producing weird standards, (pseudo-)scientific papers, consultants etc. which all don't serve one bit to improve testing itself (similar to the process talk). You just have to be careful not to waste your time on an approach that is purely academic or a bunch of buzzwords designed to confuse non-technical management into hiring consultants. ;)

RG

A good pair. dawydiuk snips all assignments. argee top-posts and deletes the entire message to which he responds. This makes the conversation crystal clear to all.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

Software Engineering ? Computer Science:

Leo Havmøller.

And in the process wasting everyones time.