Software Best Practices

 

 hi everybody,

i've been a java programmer for about 9 years. i work as a contractor in the uk. the projects i've worked on have been planned based on a range of delivery schedules of anywhere from 2 months to a year. i've worked on "greenfield" projects; as well as on "maintenance" projects (bug-fixing, redesign, etc.).  the teams i have been on have ranged from 1 (just myself) to 20. i've worked for software shops, web houses, technical service consultancies, it depts of corporations, you name it.

very often shops that i am considering working for will claim (in the descriptions posted to online job boards, say; or in interviews) that they're an "agile" shop. however, i have found - either by asking probing questions in the interview or after i'm hired  - that what they really mean when they say they are "agile" is this: "our process is adhoc; we don't follow a formal, repeatable development process; because we don't have time in the schedule for it".

in my experience it is rare for these projects to do any upfront analysis or design; rarely will these projects do any visual modelling. its not just the "traditional" software engineering best practices that they don't have time for. the same goes for the "agile" principles too! unit testing is very often a nice-to-have (if there's time); a lot of coders on some of the projects i've joined have never written a unit test in 5-plus years of programming! a lot of "agile" projects here don't do continuous integration; collective ownership of code isn't practiced or encouranged in any substantial way; most of the "agile" teams i've worked on are managed on a waterfall schedule; there is usually one (and only one) big "iteration"!

i'm not just ranting. and i'm not anti-agile. nor do i expect shops to pedantically follow the agile manifesto to the letter. the reason i'm posting is because i'm wondering is it just me or has anybody else here made a similar observation? or is it just in the uk where a lot of shops only pay lip service to the agile best practices? i am curious to hear some observations of folks on agile projects in the us and the uk.

thanks in advance for your replies.
 

We see this commonly in the U.S. too. In fact I've joked that this explains the real difference between the 1980s, 1990s, and 2000s:

• In the 1980s developers paid lip service to structured methods, but really just hacked.
• In the 1990s developers paid lip service to object oriented methods but really just hacked.
• In the 2000s, developers are paying lip service to agile methods but are really just hacking.

In other words, the more things change, the more they remain the same!

What we (Construx) have noticed in our consulting practice is that some agile methodologies seem to be more susceptible to this than others. For example, in comparing notes with other consultants both at Construx and other consultancies, it was really rare in the early 2000s to find an "XP" shop that was using more than 1 or 2 of the 12 practices of extreme programming. In practice it seemed to be mostly a way to avoid documentation and discipline, which is a little ironic because XP done right requires quite a lot of discipline.

More recently we've seen more companies embracing Scrum, and that doesn't seem to devolve into hacking nearly as often as XP did. Maybe its because Scrum is more of a management approach whereas XP has more of a technical emphasis. Scrum also seems lighter weight than XP insofar as it's not very prescriptive about specific technical practices whereas XP is very prescriptive about pair programming, continuous builds, refactoring, test first, design minimalism, etc., etc. Perhaps this is another bit of irony -- the supposedly "agile" practice of XP fades in popularity because it's too heavy weight!

Bottom line I think is that whether someone is doing agile or CMM or something else is less important than whether someone is competent in whatever they're doing. I discuss that issue more in my essay "Cargo Cult Software Engineering," which you can find here.

I don't see the point in an organization claiming that they are using the X life cycle model. It is not something to be proud of or something to be ashamed of. The main point when choosing a life cycle model is to choose the one that suits your project and your organization. You should also modify it to suit you best, you don't have to apply it blindly.

I have asked one of the MSN team at Microsoft (who are claimed to use SCRUM) and he told me that they don't use SCRUM as their life cycle model in the MSN team because requirements are somewhat specific (at least compared to other projects where you are not sure what you are going to do or what you can do in the first place). So using a loosely disciplined life cycle is not always something good in all cases.

The problem is that agile is getting a lot of evangelism today that it is getting to be some sort of new fashion that every body has to follow in order to "look good". A lot of agile evangelists claim that it is the new solution to all your management and scheduling problems, an example of the silver bullet syndrome. I don't trust an organization claiming in an advertisement or a post on a job board that they are using Agile. They are just following the new hype not choosing what is good for their project, and most probably they don't understand agile well or are not applying it well.

You can read Steve Yegge's famous blog about good agile and bad agile.

 

Hey!

You bet there would be hundreds and thousands of software engineering practitioners who would have made similar observations.

Most of the times the focus and the rush is on meeting deadlines. And in this rush, software engineering processes, visual modellings, unit tests, reviews..all go for a toss. To many shops and companies, this rush and the resulting madness is what they define as a agile process. And the process is so agile that for every milestone release for the same customer and the same project, a different process is adopted (pun intended :)).

I too have come across situations, where the team and team managers would follow the same practices..which, in every text, are highlighted in bold  as bad practices or software engineering sins.

I would like to differ from Steve's comment

"Bottom line I think is that whether someone is doing agile or CMM or something else is less important than whether someone is competent in whatever they're doing"

You can be competent even if you dont follow the rules of the game (though i suspect how long  you continue to remain competent) but you have to realize that the competency arrives at the cost of confusion and frustration within your team. While you can be agile on some aspect of the process, but some principles (like code MUST NOT go out without a review, release MUST NOT go out from a developer's machine) need to be followed strictly , which I believe is not the case with most of the shops which claim to be "Agile"

 

I don't think the original poster was talking about people aping XP in a Cargo Cult style. Rather the lip service is just that. They're not even pretending to follow the practices. They're just adopting the name. However, I think exactly the same could be said for CMM in many cases.

And that's not to say that there aren't developers out there giving these techniques a fair try. It's just that when they do, inevitably, the results fail to reflect the hype. At this point, instead of encouragement, they are told by the "experts" that they're doing it all wrong. Presumably in case the opposing "experts" seize the opportunity to highlight the failings. And so the cycle continues with the next flavour of the month. This is what I see happening most of the time.

 

I would like to differ from Steve's comment

"Bottom line I think is that whether someone is doing agile or CMM or something else is less important than whether someone is competent in whatever they're doing"

You can be competent even if you dont follow the rules of the game (though i suspect how long  you continue to remain competent) but you have to realize that the competency arrives at the cost of confusion and frustration within your team. While you can be agile on some aspect of the process, but some principles (like code MUST NOT go out without a review, release MUST NOT go out from a developer's machine) need to be followed strictly , which I believe is not the case with most of the shops which claim to be "Agile"

I don't see how this differs from my comment. If the most competent thing to do is "follow the rules," then that's competency. In other cases, "following rules" could be too simplistic, and in those cases adhering to more general principles but not to a specific set of rules would be competency.

This reminds me of the article published years ago about the "CMM Immaturity Model" that went from Level 0 to Level -2. I agree that just paying lip service to a set of practices without even trying to ape them is even worse than what I described in "Cargo Cult Software Engineering."

Of course it's true that there are lots of developers trying to give these techniques a fair try -- hopefully that's what the people on this forum are trying to do :-)

Steve

I am sorry but I took competency in a different context and most of the shops I have come across - competency to them primarily means getting the product out to the customer on time.

My point was, that in an attempt to be agile with the processes, many organization tend to dishonor even the basic rules. The result is, though the product is out in time, but the team goes through a lot of struggle and confusion which otherwise could have been avoided if the basic rules were followed.

Regards

Simer

Steve McConnell:

XP done right requires quite a lot of discipline

 

Amen!

I introduced XP into a company I worked for a couple of years ago. At first, all was great. It was fun, we delivered great software, and we learned a lot (like pair programming is really hard and exhausting, but also very gratifying). Then, some miscommunication happened. We rewrote a significant part of the product (since it wasn't testable), whereas the CEO thought we would just change a couple of lines of code. It took us three months instead of something much smaller that he anticipated. His immediate response was to forbid pair programming.

People can't really learn if they are not allowed to make mistakes. And if we don't learn, we stick with what we know: CMM level 0 ;-)

Steve McConnell:

Of course it's true that there are lots of developers trying to give these techniques a fair try -- hopefully that's what the people on this forum are trying to do :-)

 

That's why I'm here :-)

PS. I just want to say thanks to the Construx folks for putting this forum together. I really hope it doesn't fall victim to the process wars.
 

sinnema313:

Steve McConnell:

XP done right requires quite a lot of discipline

 

Amen!

I introduced XP into a company I worked for a couple of years ago. At first, all was great. It was fun, we delivered great software, and we learned a lot (like pair programming is really hard and exhausting, but also very gratifying). Then, some miscommunication happened. We rewrote a significant part of the product (since it wasn't testable), whereas the CEO thought we would just change a couple of lines of code. It took us three months instead of something much smaller that he anticipated. His immediate response was to forbid pair programming.

People can't really learn if they are not allowed to make mistakes. And if we don't learn, we stick with what we know: CMM level 0 ;-)

 

Sometimes, when I try to write things down I understand that I don't understand. In such cases documentation helps me understand myself and avoid confusion. Do you think it was the case when a little bit of documentation would help avoid any confusion?
 

Steve McConnell:

...
Bottom line I think is that whether someone is doing agile or CMM or something else is less important than whether someone is competent in whatever they're doing...

i guess it depends on whatever the criterion for competence is. a lot of developers think that being competent means only knowing enough of the syntax of a language to make their code compile; or only knowing enough about their ide to be able to checkout and build projects, and correct the errors raised by the ide's syntax highlighting feature. for a lot of developers competence means having a photographic memory of the signatures of every single method in a specific set of APIs. for some, the "most competent" coder is the one that can write the most complex algorithm; or the one that can hand code a custom data structure that outperforms an existing data structure from the standard libraries of their sdk. for a lot of people that make or influence the ultimate hiring decisions, you coud be grady booch and they wouldn't hire you if you didn't have certain things on your resume. the only competency that matters to them is experience in a specific problem domain (banking, or applied cryptography, say). very rarely has, "ability to expertly apply software engineering best practice" been listed in the must-have section of the job specs i've come across.

 

My take is: regardless of what label you put on a collection of suggestions for how to produce software, and regardless of how competent a person is at their chosen “core skills”, i'm convinced that following proven best practices and shunning others will always lead to better efficiency. that was true in the 40's and 50's and it will be true in the year 4050!

 

by "efficient" i mean things like:

 

1. not wasting time by writing the exact same code for the current project - or current class - that you or maybe another team member wrote for five previous projects. writing redundant code is a waste of time.
2. not wasting time reinventing the wheel!
3. making it as easy, as quick and as unambiguous as possible for a new team member (or ANY team member for that matter) to understand the system or the subsystem he's asked to work on. it has been scientifically proven that there is no easier, quicker or less ambiguous way for humans to understand something - and retain that something in memory - than by looking at a picture of that something.
4. not wasting yours and your team members' time by doing things manually when there are software tools to automate the tasks.
5. program to an interface; not to an implementation
   

 

those are just a few generic best practices. smarter guys than me (guys like steve mcconell ;¬) have already written books listing and explaining specific best practices way better than i can. And the thing is: it’s not rocket science!

 

So why is it so difficult for the majority of developers to follow software engineering best practices? this question really perplexes me!

 
btw, i know i'm probably preaching to the choir here. i doubt that the "natives" would be attracted to this kind of forum ;¬) but its healthy to vent somewhere. at least you guys know where i'm coming from. thanks for that article btw, steve.

sinnema313:

...Then, some miscommunication happened. We rewrote a significant part of the product (since it wasn't testable)...

 

in my experience, team members and customers don't always communicate with each other as simply and as unambiguously as possible.

 

a verbally spoken instruction or request can be easily misinterpreted. the same goes for a written instruction or request. words can mean different things to different people. more and more these days, we are all working with team members and customers whose native language is different from our own. that increases the risk of misinterpretation. even people whose mother tongue is english don't always have complete mastery of the grammar or vocabulary of the english language.

 

add to that all the geek-speak, jargon and acronyms that us tech-types like to use; mixed in with the domain-specific jargon and acronyms from the lexicon of the customer's industry. talk about your tower of babel!  the astonishing thing is,  best practices to mitigate the risk of inevitable misinterpretations have existed for years! but like simerjeet aluded to in an earlier post, most shops have tossed it and the baby out with the bath water!

 

imagine you're in a foreign country; you can't speak the language; you're in a food shop; you wanna buy a piece of fruit; which of the following 2 methods do you think would be the most unambiguous way to let the shopkeeper know what you want?:

 

1. method #1: after fumbling to remember the foreign word for the specific piece of fruit you had in mind; you not only guess the wrong word, but you mispronounce it as well; out of confusion and misunderstanding, the shopkeeper gives you a can of dog food instead of the specific piece of fruit you thought you asked for; you reject the can of dog food in disgust; you make another attempt at pronouncing the word; you're handed a sack of potatoes...see where i'm going with this? sounds familiar?
2. method #2: you show the shopkeeper a picture of an apple. he gives you an apple. you pay him. the end.

 

now, let's say you took 2 developers of equal competence (measured by any of the criteria mentioned in my reply to steve mcconnell above):

 

• say one developer used an approach analogous to method #1 (what i like to call, "verbal modelling") to build some software to a given specification.
• and say the other developer used an approach analogous to method #2 (known in the trade as, "visual modelling") to build some software of the exact same specification.
  

 

which one do you think will finish the job sooner? which one do you think the customer would be most satisfied with?

 

my point is: a picture is worth a thousand words. i just don't get it when people say they don't have time to do visual modelling. they think they're saving time by not doing things like analysis, visual modelling or writing use case specifications (or "user stories", or whatever you choose to call them). but it’s a false economy! you would save yourself a lot more time IN THE LONG RUN, if you do certain things up front. there's nothing inherently un-agile about uml and ooad.

 

so i guess it comes down to competencies again. my theory is that people choose to be competent in areas other than software engineering best practices. or they’ve been CHOSEN BY whoever hires them because they are competent in areas other than software engineering best practices. people don't like to attempt things they know they are not competent at because they don't want to look incompetent. have any of you guys seen evidence of this in your experience? does the theory hold any water?

 

for me, the operative word in "best practice" is "practice". we can read all the books on software development we want; we can talk about the cool new trends and spout off acronyms and buzz words to impress our colleagues until we're blue in the face. but it don't mean diddly squat without practice.

 

again, i know i'm preaching to the choir here. and i definately wasn't implying that folks here aren't walking the walk. i just think this is a point worth  repeating.

PS. I just want to say thanks to the Construx folks for putting this forum together. 

We've been thinking about this for a long time, so it's great to see it finally up and running.  

I really hope it doesn't fall victim to the process wars.

Me too! I hope we can have some good in-depth discussions about process as well as great discussions about many other topics.

 We have a development process where we've selected a range of techniques drawn from Agile, XP, RAD, and others so that we can scale it to our projects at the same time as applying it to both software and systems engineering.

The problem we have with terms like Agile is that it advertises to project and business managers the prospect of savings. They think agile means thinner, quicker, easier - a way of possibly improving productivity.  It's the same with any methodology buzz word so we have to decrypt the messages and point out the implications for project controls, quality indicators, defect tracking, and all the rest in order to restore calm.

A good example is where someone thought that Agile allowed continuous change of requirements without impacting the quality of the deliverables. It was only when we explained the implications and the risk in a market with fixed deadlines and contractual requirements that they paused a little.

I wonder what the impact would have been had the methodology been labelled "Careful" or "Extremely Meticulous" :)

 

I guess you wouldn't have heard of them. I think it's easy for good stuff to get ignored in favour of the latest bandwagon. I'm not sure what you're suggesting about changing requirements. The ability to change requirements at any point in development without seriously hurting quality is a defining characteristic of Agile approaches. But that doesn't mean there are no consequences to changing direction. The trade off is either scope or time. That is, you'll either end up with a smaller product, or it'll take longer to build. If your contract is fixed time and fixed scope you'd be unable to use an Agile method without breaching those terms.

Nick Kisialiou:

Sometimes, when I try to write things down I understand that I don't understand. In such cases documentation helps me understand myself and avoid confusion. Do you think it was the case when a little bit of documentation would help avoid any confusion?

 

I don't think so. The problem was that the development team talked to the development manager and the development manager to the CEO, but the team never talked to the CEO directly. This little anecdote shows you why XP wants the customer to be on-site.

Besides, that wasn't my point. Making mistakes is a natural part of learning, and we should allow for it to happen (as long as we do learn from it ;-)

 

Paul Sinnett:

The ability to change requirements at any point in development without seriously hurting quality is a defining characteristic of Agile approaches. But that doesn't mean there are no consequences to changing direction. The trade off is either scope or time.

That's our problem with Agile as a whole - we have mostly fixed time fixed scope projects without a customer on site. Nevertheless, there are elements of the Agile approach which we've found useful in customising our own development process. We use buddies as a control check, highly iterative development wherever possible, frequent integration with automation, interim builds, and so on.

Where we have projects which are used in multiple products, frequently needing to integrate into already deployed systems, accepting change means we have to control it tightly. Agile doesn't seem any more capable of dealing with this conflict than any other methodology. It only seems easier because the context is assuming software as a stream, with negotiable time and scope. Given those conditions, we'd all find it a lot easier to incorporate change without hitting quality.

 

I haven't read any literature about 'agile' but I know that they become buzzwords when people don't truly understand them, e.g., just like CMMI, and thus misrepresent them.  When people say they do this or they have been assesses or they have been certified, I always look for evidence both quantitatively and subjectively.  Here in the Philippines, when the CMMI bug bit us, I heard horror stories about companies closing shop after being assessed.  Reason:  The executives started their own consulting businesses waving their CMMI experience.  'CMMI', 'agile', 'PMI-certification' have all become advertising components.  Of course, not all stories I heard were bad.  Some actually benefited from institutionalizing practices encouraged by CMMI.

Personally, methodologies, models, standards useful as they are aren't as important as integrity, respect for all stakeholders, and common business sense.

 

 I certainly agree that there's a lot of hype and misunderstanding about what counts as agile. The drivers for managers seems to be cutting or limiting costs, shortening timescales, and reducing time spent on writing anything other than code and whilst it looks like it might be the right business decisions, it can create problems on projects.

If the agile principles are taken at face value, we can get some quite dangerous assumptions actually implemented on projects which are already in difficulty. For example, if it's really believed that self-organising teams will evolve the best architecture and design iteratively through face-to-face communication, we can end up with poorly equipped teams left to "get on with it" as a response to the diffuculties with a consequent blame backlash when they understandably fail.  Of course, any self-managing team could manage itself well or badly, and in some cases, a good design might emerge.

What I find is rarely appreciated is that all development methodologies imply some process risk and the trick is to choose your risks to be consistent with the project, and to manage them. For example, evolving a design implies carrying some higher project risk which may be justified and mitigated by for example, close customer contact. On the other hand, working to develop a large-scale tiered architecture which requires detailed defined interfaces would introduce risk if those interfaces were evolving for a continuous period (for example the risk that functionality is not testable) so that process risk may not be sufficiently mitigated by development advantages.

When managers try to use the buzzwords to backfill the missing risk management by cherry-picking some techniques, they can very easily derail a project and create confusion. In my experience, the business requirements of projects (contractual time-scales, key milestones, fixed budget and time constraints) impose quite rigid controls which a development methodology has to work with.  If we can't negotiate the delivery of a stream of software with flexible dates and very few constraints, we have to adapt the methodology to the project.

Having said that, many managers have an overly linear approach. Although there's always some linearity (requirements -> product), it's a long way from a production line and perhaps it's the difficulty we have getting across the non-deterministic nature of software development that makes development managers more susceptible to the buzz words.