Why Greenfield Development Is Not The Solution To Your Brownfield

Facing a Brownfield project, the obvious solution is to start over. As a general rule this does not work. Which does not mean it cannot work in isolated instances.

Consider those Brownfield projects that are so bad you or your client are willing to abandon everything and start over and do it all again. There must be multiple problems in the Brownfield. These problems have probably reached an unworkable state. Working on one problem creates other problems. One problem prevents working on another problem. Perhaps the source code for a COM component has gone missing. (I do not know what it is about COM but since it's widespread use, every company seems to have a COM component with missing source). Or perhaps knowledge of the inner workings of the system is missing. Perhaps the original perpetrators of the code have fled the scene of the crime.

So the motivation for fixing the Brownfield is the ability to fix the multiple problems. This is also why the Greenfield approach will fail. You have a mandate to fix everything in the Brownfield. But this is too much to be attempted at once.

It is not that you can not fix each of the problems in isolation. It is the combination of problems makes it exponentially more difficult. If lack of knowledge (like missing source code or fled perpetrators) is added to the mix, you will be flying blind. You may think you know what the component is supposed to do but there is tribal knowledge embedded in the source code.

But lets suppose you have jumped off and started the Greenfield to fix your Brownfield. As you solve the problems, the solutions will start to compete with each other and to a certain extent some hard trade offs will emerge. Some of these trade offs are what caused the original nest of problems in the original Brownfield. Thus the Greenfield becomes a Brownfield.

So it then becomes a race. Can you get all of the features implemented in the new Brownfield before being overwhelmed by the toxins being created.

Donald Knuth Dams Waterfall

Quoting from an interview in "Communications of the ACM" 2008 08 with Donald Knuth:

The setup is Donald had written a complete spec and assigned it to bright students and then did nothing to manage them as they implemented the spec.

"To my amazement, the students, who were outstanding students, did not complete it."

Only later when he tried to implement it, did he find that it was not so easy.

"Because going from my specification, which I thought was complete, they had an impossible task..."

He later goes on to point out that even with the most complete of specifications, questions arise every 5 minutes as you write code.

In effect, his approach was waterfall with a Big Design Upfront. What he found was a cornerstone of Agile practices, you need to implement a portion of the project and then you will learn enough to start asking questions.

Database Deployment Challenge

Getting a database deployed consists of numerous challenges.


One issue is simply getting the database engine deployed and configured. One might add purchasing to the list as well as getting a licensed copy can be challenging in some companies. An obvious workaround is to use an existing database engine. The Registry serves as an excellent database for configuration information. The Event Logging system of windows is an excellent database for logging. Another common workaround is to use flat text files or xml files. You will still need a database engine, it just may not be apparent because you will be writing it in your program.

The next issue is getting the initial database schema in place. With a traditional engine like SQL Server this is challenging. The best solution is to use DataDude (also known at Microsoft Team System For Database Professionals). In the case of using built in engines like the Registry and Event Logging system the schema is in part dictated by the system and in part created as part of your install. The current setup project that Visual Studio creates makes Registry and Event Logging easy to maintain. In the case of flat text files or xml files, the schema is part of the file. Again the unseen trade off is you will be expending some effort in your code enforcing the schema.

The final deployment issue is getting the initial data in place. If you are not using the DataDude by now, you will find your database deployment has reared up and become a project unto itself. In the case of the Registry and Event Logging the initial values are created at the same time as schema is installed. And in the case of the flat text files or xml files, it is part of the file.

When looking across these options, it is easy to see that the flat text files or xml files present the easy path. The downside will occur later when the data must be shared with other programs, or performance issues arise. So the hard thing to do, but the right thing from an architecture view, is to force configuration information to be stored in the Registry, logging must be stored in the Event Logging system. And for other data, a database engine must be deployed and used.

Five Things That Come First

In reading "Writing Secure Code" I was heartened to find the author state "Security is a top priority". The statement as whole is not surprising for the book but the use of "a" as in "a top priority" instead of "the" as in "the top priority" was the comforting part.

Reading Roger Session's blog on code complexity, Roger implies that complexity is more important than security. As in if the code is complex it can never be secured. So that would imply Complexity (or reducing it comes first).

The Test Driven Development movement preaches Test First. It should be noted, code is not testable by default. You will always need to do something to make it testable.

Any book on Scalable Architectures will tell you, you must design from the start for scalability. So add Scalability to the list of things to be done before anything else.

I myself have learned the hard way to do the install first. But having an installer does not guarantee that your software will be deployable. So but Deployable on the list as well.

Thus you end up with Five Things That Come First before you even write your first line of code.

Security
Scalability
Testable
Deployable
Complexity

Open Source's Infinite Budget: Part 2 Your Company

Open Source has an infinite budget

As I discussed in Part 1 The Community, the open source community is not the source of this infinite budget. In fact the Open Source projects are overrun with bugs and security breaches and as such are turning to various Clopen models to generate revenue. Most of the Clopen Source modes are failing. (The notable exceptions are using a variant of Clopen Source which can be called Corpen Source which I will address in another post.) So if the infinite budget is not in the community where is it?

If you have allowed a free reign of open source in your company then it is coming from you. And it is being spent in a way that should alarm you.

Suppose your company allows the use of any and all open source tools. To the developer this is functionally the equivalent of an infinite budget for open source tools and software.
Whenever the developer wants a tool it's purchase is automatically approved because the price "free" does not reduce any budget.

He then can start using the tool and all is well.

Provided of course that it stands alone and has no bugs or security problems. Oh and provided of course that he does not need to learn how to use it. But if it needs to be integrated or bugs need to fixed then the budget that pays for it is hidden from management.

The developer will be spending hours integrating or fixing or working around bugs. These hours come out of the finite number of developer hours available to you. Note there is no check or limit on how much effort will be spent on supporting open source in your company, as such the budget for open source that you are paying is infinite.

So what is the moral? Never use open source software?

No, the answer is harder than that. What is called for here is management. Management means monitoring and making some hard decisions based on facts. Some open source software, NUnit would be may favorite example, is almost defect free and can be easily used with little integration or learning ramp up time.
But keep an eye on these, even if you stick to solid open source software, the integration costs increase at a factorial rate as the number of components increase.

There will come a time when you should opt to use a development stack and pay a flat fee instead. MSDN is a great example. For a few hundred dollars a developer (partner pricing) you can get access to all the software needed and at the same time the integration costs disappear.

Backing Down A Bug

So a bug is found in production.

In spite of your following all the best practices.

You had separate environments for Development, Integration, QA (testing), UAT and Production.

You have been doing versioned releases and following your documented change control procedures.

You had a QA staff that did it's best to test for and find all bugs.

You have three levels of help desk or technical support.

And in spite of this a bug made it all the way out to production and it must be fixed. And the business side of the house is flipping out and the pressure is on. Fix the bug now!!

How you handle this will determine if your company grows and gets a tiny bit better. Or should you fail, you the company will plant the seeds of disruptive behavior that will haunt you for the rest of your tenure.

You must avoid the temptation to storm in and take things over. You need to Back This Bug Down From Production with the care you would back a jumper from a ledge.

First make sure that the help desk or technical support was engaged. If not, engage them. Use this as learning opportunity for the support staff to learn how to mitigate or work around bugs in production. Should you find a work around, you must insist to the suits that it is over. A work around has been found. The work around is in place. Both the bug and issue (the issue is how the bug made it to production) are being researched and will fixed in later release. End of Story. Do not be stampeded on this.

Now chances are good that a work around is not immediately found. In this case, the backing down starts. QA must take a role here. At this point QA has tested the application and their job is to get the bug reproduced in the QA environment. Again, you must resist the desire to jump in and take over. QA has an important role in defining the bug. If QA can reproduce the bug in the QA environment, you should then be able to use this information to reproduce the bug in the Development environment. When you have fixed bug, QA will now be in a position to test the fix. This would not be possible if you had ripped control away from Tech Support or QA.

But this is not the end of the story. There is still the open issue of how the bug survived your processes. Inevitably something is missing in terms of testing or the processes were not followed. Fixing this issue will prevent future bugs.

Obsolete's Key Role In Agile Software Development

There is one attribute that has a unique and powerful roll; Obsolete.

Here are four examples applications to the same function 'Funky'

1:
[Obsolete()]
void Funky(){...}

2:
[Obsolete("Use Freaky instead")]
void Funky(){...}

3:
[Obsolete("Use Freaky instead", false)]
void Funky(){...}

4:
[Obsolete("Use Freaky instead", true)]
void Funky(){...}

Starting with 1 you can use this attribute without any of the parameters. In this default mode it will generate a warning indicating the method is obsolete. Following the rule of "Making the Right thing Easy and the Wrong thing Hard" this should be avoided in favor of 2; Use the message string to explain what should be done instead.

Example 3 is equivalent to 2, the second parameter determines if the Obsolete attribute results in a warning (false, the default) or an error (true). It is rare that you will actually have this set to true (4) and checked in to source control, since that would break the build. But it does happen and it is a more elegant way of making "The Wrong thing Hard" than commenting out the obsolete code.

How you will use 4 is to explore the level of effort involved in changing code. In a typical "Drain A Swamp" effort; the code might not even compile from source control without error. After considerable effort you will get the errors out but be left with numerous warnings. This morass of warnings will hide the ones generated by Obsolete. So working with generate error set to true will provide a count of what is left and a road map of what to fix.

In Green Field efforts Obsolete provides a effective means of communication of intent between teams working on separate modules. It raises the flag that one team wants to change something but does not force another team to change immediately. Perhaps the second team needs to transform and obsolete some code as a result. On balance it allows for teams of programmers to behave in an agile manner.

But perhaps the best benefit of Obsolete is the knowledge that it is there and provides a way for a programmer to take back his mistakes. What is not stressed enough about Agile methodologies is that it is a safe way for programmers to make mistakes. This frees them to discover things that can never be known beforehand in a Command and Control Central Planning mode of development. By fearless experimentation and ruthless obsoleting programmers will flow past problems, discovering the easy way much like water finds the downward path to the sea.

Bright Shiny Objects

Bright Shiny Objects abound.

If you attempt software development for any length of time you will encounter Bright Shiny Objects. They come in multiple forms. They could be the latest features your competitor has in their products. They could be the latest language, which uses the latest language feature, which will save us from the latest looming Y2K disaster. Or it is a new platform which will make everything self managing. The list is endless.

If they have one thing in common it is newness. All things new tend to have bright shiny exteriors. Part of the draw is simple curiosity. But for developers of any moderate experience there is a deeper pull.

As I pointed out in “The golden first year" you get paid for your experience. Thus you get paid in your next job for what you did in your current job. If you lived thru the tech bubble you saw this first hand as html developers were paid more than client server whizzes.

Technical people are excellent problem solvers, so it does not take them long to realize this dynamic and solve it by loading their current project up with all the current hot Bright Shiny Objects.( Your website may have no real use for AJAX but you have it now.)

The danger is Bright Shiny Objects tend to be loaded with Poisoned Candy. Poisoned Candy are those features or tricks that make the Bright Shiny Objects work in limited circumstances like development or in a beta situation but fail horrendously in production.

Unless you are eternally vigilant, you will find your project overrun by Bright Shiny Objects and their problems. If a developer wants to use a Bright Shiny Object, you are going to find it nearly impossible to stop them. Keep in mind, that even if you control their employment, they perceive that the market will reward them with a better job in the short term if they can master this technology.

So what can you do?

Insist on Small Doses and Results. Ask the developer to do the smallest thing possible with the Bright Shiny Object, and give it a short deadline; a day or something less than a week. If it is more than a week it runs the risk of evolving into a project of its own. As soon as something is displayed insist on running it through the entire process all the way up to the edge of deploying it to production. This will reveal all the poison in the candy.

Occasionally there is no poison and you have found a better way. Congrats and beware. The more likely case is a mixture of good and bad. Here you will have to insist that the defects be remedied by making the developer address them. By sharing this pain with the developer they will start to gain an understanding for the dark side of Bright Shiny Objects.

Easy To Do Right, Hard To Do Wrong

Easy To Do Right, Hard To Do Wrong

Part of the reason that technology workers are compared to cats (managing developers is like herding cats) is a misunderstanding of how their work is structured.

Quite often rewards are given for doing the wrong thing and the right thing is punished.
Praise is given for pushing a release out before it is ready.
Even more praise is heaped upon them for fixing the bugs in the early release.
Yet more praise is layered on top for tracking down and fixing all the data corrupted by all the bugs that were in the early release.
And on and on.

As a manager of technology workers the goal is to put in structure so the easiest thing to do is the right thing. And it is at the same time hard to do the wrong thing.

Take the one two three combo of 'Source Control is Authoritative' and 'Daily Build' and 'Automated Builds'
By insisting that the only code that matters is the code in Source Control, you make it hard for developers to create local branches that are far out of date with the main branch.

The 'Daily Build' reinforces checking in often and verifying that all local dependencies are fixed.
The 'Automated Builds' make it easy to verify that the checkin have not broken the code.

Interviewing For Big Project Experience

In Interviewing For Artifacts :

I introduced the idea of assessing for candidates by looking like an archaeologist for the artifacts of experience. Skill in a language will tend to create a familiarity with all the keywords of the language for example.

When assessing candidates for big project experience a similar approach can be used with a slight adjustment. You need to define what is motivating the desire for big project experience. No doubt the current project or the project you are about to start will be a big project. What are the difficulties you have experienced or expect to experience?

Process is a typical candidate. Usually with large projects you need heavier processes to both keep the project on track to the intended goal and to assure the project is making progress.

Sometimes the complexity of the code is the issue. You know the project will be compose of multiple assemblies, libraries or components.

Another common source is the need to leverage a large preexisting code base.

There are others, for them follow the pattern I will describe for the previous three.

Start off by asking the interview to describe the biggest project they have done. You are hoping for a brief synopsis or overview so that you can ask followup questions.

If the candidate responds with a project that is small then you are done. He has no big project experience.

On the other hand if the candidate describes a big project, you will then need to followup to see if they gained the experience you are looking to find. The first followup question is also simple; What challenges did you encounter?

If you are lucky they will describe the problems you encountered. If not you will then need to ask a leading followup question. One of :

What sort of processes were used, how did they affect the way you worked?
How many assemblies were there, what were their purposes, how did they interact?
Did you have to use a preexisting code base or framework?

What you are looking for is that the candidate encountered the problems you expect them to handle and that they learned from the experience. Now as a friend of mine pointed out, usually what he learned is he never wanted to do that again. I have had candidate express this feeling during interviews.

It is a mixed bag. On the one hand it is clear evidence of experience on the other hand, especially in the case of process, it may indicate they will not be happy in your environment. You should recap at the end of the interview that the job involves this particular challenge.

MsTest and NUnit; Using Both

If you can use MsTest; you should. The integration benefits will pay dividends over and over.

But if it is not available across your company, you need not settle for the least common denominator of NUnit. And you may want to develop with MSTest but deploy with NUnit to keep the footprint light.

Fortunately there is an almost one to one mapping between the namespaces of the two.

So using the following conditional code at the top of your test class file, will enable you to alternate which testing harness you use.

==============
Code Start

==============
#if MSTEST
using Microsoft.VisualStudio.TestTools.UnitTesting;
#else
using NUnit.Framework;
using TestClass = NUnit.Framework.TestFixtureAttribute;
using TestMethod = NUnit.Framework.TestAttribute;
using TestInitialize = NUnit.Framework.SetUpAttribute;
using TestCleanup = NUnit.Framework.TearDownAttribute;
using ClassInitialize = NUnit.Framework.TestFixtureSetUpAttribute;
using ClassCleanup = NUnit.Framework.TestFixtureTearDownAttribute;
#endif
==Code End==
Some things like Categories have no direct equivalent so you will need to conditionally compile their attributes:
==Code Start==
[TestClass ]
#if MSTEST
//Intentionally empty
#else
[Category("Web Service")]
#endif
public class QA_Feature_2_1
==CodeEnd==
And another gotcha occurs around the test and suite set up and tear down functions:
==Code Start==
[ClassInitialize()]
#if MSTEST
public static void MyClassInitialize(TestContext testContext)
#else
public void MyClassInitialize()
#endif

=========================

Art of Software Development

The short answer is their is none.

Software development is a science. It should be treated as such. So it is always perplexing when software developers are referred to as artists or the software development process as black art.

Go ahead and Google the words and you will be overwhelmed.

Read a good sample of the articles and you will not an underlying surrendering to the developers by quite a few.

This does not need to be the case. Other complex fields are successfully managed and applying some of the principles found software development is also manageable. To take three under used principles Accountability, Responsibility and Transparency would be a good start. Applying the three starts software development down a road of Repeatable and Testable actions. This in turn makes software development into a Science.

How to not do QA.

I write so much about QA you would never know that my primary focus is software development.

There was not one event that formed this unshakable belief in QA. (Just to refresh..Good QA can save you from bad developers but good developers can never make up for no QA.)
But I can recall several first hand experiences that drove home this painfully gained experience.

And looking back, they all have a common theme of:
"How can we do this without QA?"

Here are three approaches that were tried and where I directly felt the pain:
1. Have the customers test it.
2. Have the engineers test their own code.
3. Have the engineers test each others.

The first one, of having the customers test it, was at the insistence of a bright individual who insisted that there was no time. We had to get it to the market now. This was at the same time that we were trying to get a round of formal testing added to the project plan. I did not have a lot of experience at the time and neither did many of my colleagues but we instinctively knew this was a really bad idea. Another bone of contention was getting a cycle to fix anything found in testing together with another round of testing.

What was offered was; we will do a limited beta and fix all the complaints that our users told us about. An obvious difficulty we had with this proposal was that we could not get to our customers machines to see what was wrong or experiment with fixing them.

The compromise was we would have everyone in the company install the product. That is we would use ourselves as 'internal customers' first. Then we would quickly do an external release.
This failed miserably. Not surprising since this was an untested product that was developed against one environment that was deployed through out a company with numerous differences between the machines.The only upside was the failure was so grand that we did not move on to victimize the external customers.

The second and third options of having the engineers test, either their own or each others ended poorly. I was with a company that after a round of layoffs that included nearly all of the QA group, announced that the software developers needed to test their own code. This way we could keep all the products alive for less cost.

At this point you should step back and wonder, if this is a successful practice, why haven't we done it from the start?

Of course this failed miserably. The first release without QA was the second worst one ever. Features were colliding with each other and numerous bugs were added. In hindsight the best thing would have been to back out the release and deputize some developers to be full time QA.

This was not to be. Instead we followed up the second worst release with the absolute worse release that was to be a "bug fix only" release. What went wrong here was all of those bugs that were introduced had not been found. At the same time, our reliable means of verifying features and bug fixes and now most important assuring no regression bugs was gone.

Now I mentioned that the way out might have been to "deputize some developers to be full time QA". This sounds an awful lot like "Have the engineers test each others code."

The key difference is that in the first case they would be "Full Time", in the second case they would be "Part Time". I have experienced the benefit of 'part time' QA. The feeling that the other engineers are just 'phoning it in' is the best you can hope for. In reality what that other engineer wants to do is get this testing over with as quickly as possible so they can get back to the fun of actually doing what they consider real work.

So there you have it. Three ways to not do QA. They do not work, since you did not do QA.

Feature Focus or Bug Focus

What is more important Features or Bugs?

If ever there were an acid test for maturity in Software Development perhaps none is better than Features or Bugs. What is most important implementing a new feature or removing existing bugs?

If a developer is focused on features then they have a Feature Focus. Bug Focused developers give precedence to fixing bugs first.

Which is better? Fixing bugs. Which do new developers prefer? Implementing new features. Only over time do developers realize that as their bugs accumulate, their ability to implement new features becomes ever more difficult. One day they will experience the truly awful feeling when a newly revealed bug shows that a recently added feature will have to be completely reworked.

So what do you do if you have a crew of Feature Focused developers? This is a common problem. One solution is to use QA to give them an external souce of Bug Focus. To do this, you must be prepared to step in and support QA. At the same time you must dampen the praise given for new features. This is also simply done by insisting that only releases which have passed QA will be demonstrated.

UAT Environment

User Acceptance Testing, UAT for short, also goes by the name Demo or Demonstration.

If you have a somewhat typical set of environments setup to support software development, they will correspond roughly to the following:

Development (DEV)
Build
Integration (INT)
QA/Test
UAT
PreProduction
Production (PROD)

How these are used also varies slightly from one company to the next but some key concerns are addresses at each level.

Build ensures the code is in Version Control and always builds.

Integration ensures the code under development and third party code, software and legacy systems all still work together.

QA or Test validates the ever increasing feature development and bug fixes.

So it may seem like UAT is overkill. But it is precisely because the previous (lower) environments have checked out and passed on all these details that allows UAT to provide the first chance for the Customer to provide their feedback or approval. The system is in a state where it could be deployed , all of the bugs and issues have been resolved.

But it is precisely because the Customer is providing feedback here that Software Developers will be most insistent on gaining access to the system.

One reason is familiar, they need to fix something. The answer to this is the same as it was on QA, fixes should flow throught the process to keep the version integrity. (Although QA should have already found the bug so if this is a new bug, some investigation should be done to determine why QA missed it.)

Another reason is the Customer is changing their mind. Here Acceptance is called for, not only will the Customer change their wishes, they may never stop. Sometimes they flip flop between several implementations. Sometimes there is more than one customer and they cannot agree. In this case you will need to find a way to make the different options configurable. This will need to be documented in a Use Case and follow the process of every other enhancement.

But the best reason for keeping Developers off of UAT is to see "Can this solution live without the constant care and feeding by Developers?" Even better "Can mere mortal users actually use this system?"

permalink

All that Team System

Say anything about Microsoft Team System and chances are you will be wrong because your information and/or understanding of Team System is incomplete.

Version Control is all new. Most of what you know based on SourceSafe no longer applies. Much of the rationale for using alternative version control systems is no longer true. Keep your eye on changesets.

Risk Tracking is a new feature introduced with Team System. You may have developed or purchased a separate system for this. You will have to reconsider because this Risk Tracking system is natively integrated with Version Control.

Bug Tracking is also a new feature of the Team System. Again you may already have one in place. And again you will have to reconsider because the Bug Tracking system is natively integrated with Risk Tracking and Version Control. Notice a pattern? It goes deeper recall those changesets that Version Control uses? The resolution for a bug can include links to the changeset that fixed the bug.

Work Item tracking follows the same story, integrates with Bug Tracking, integrates with Risk Tracking, integrates with Version Control. Again huge benefits from linking the changesets that satisfy the Work Item.

Unit Testing, Regression Testing, Performance Testing, Environment Testing; again integration with all the rest of Team System.

Likewise the Build features of Team System.

Now it is possible that you have cobbled together a collection of systems that do all of these things. Perhaps you have even integrated them and managed to get them to work together. If this is the case then there are two very probable outcomes. One is that significant effort goes into keeping the patch work collection of systems working. If not then certain quirks, annoyances and bugs is just tolerated and worked around on a daily basis.

But that isn't the end of the story. There are more features to Team System, plus we just got an update with version 2008 that contains even more. One could despair of ever catching up on this one offering from Microsoft.

But there is hope. When Visual Studio came out there was a similar flood of features, and with each new version of Visual Studio more tools were added. We never caught up with Visual Studio. In a way we never had to catch up. We just started using it. The more we learned the more efficient we worked. It was always a balancing act between getting it done and spending time learning how to do it easier. We survived the Visual Studio feature flood. We will survive the Team System feature flood. And what a great problem to have!

permalink

Separation of Concerns

Software developers can test do all their own testing.
But it will not work out.

Software developers can also plan and envision the product.
But this overtime will go astray.

What drives sustained success in software development is Separation of Concerns.
Which sounds like Specialization but is not.

The best example is Accountants and Auditors. An accountant can by changing the rules, change the profitability of the company (think depreciation). So over time accountants have showing a profit, and ever growing one at that, as their main concern. Auditors on the other hand are only concerned with how the accounting processes and practices are done. Auditors have no concern for the whether a profit is shown but rather that the profit and loss number was arrived at in an acceptable and consistent way. When your accountant becomes your auditor as well, or when you auditor accepts at face value all that your accountant does you can expect an Enron type outcome.

Software Development is different because it has three concerns that need to be separated; Specification, Implementation and Validation. It is better to think in these terms rather than the roles that they are usually mapped onto; Business Analyst, Software Developer and Tester/QA. Business Analyst implies some concern for the business as whole. Test is close although it emphasis is on bugs and Quality Assurance takes the focus on Verification.

Specifying what is to be created must be completely separate from Implementation, which is how it will be created. Time and time again the pattern repeats of software developers pushing back and not wanting to implement something because it is hard. Or it does not lead to using the technologies or practices that are currently fashionable. And by fashionable, I mean well rewarded by the market place. If you hold both concerns of Specification and Implementation at the same time the temptation to make a comprise on Specification to benefit Implementation is immense.

When it comes to holding Implementation and Validation concerns at the same time the problem is even worse. Testing may reveal a problem. Knowledge of what it takes to fix it hinders the desire to immediately log it and raise it as a concern. Here again compromising Validation to benefit Implementation is the easiest route.

To keep this in the proper length I will state the next four and return to them later with separate articles:

Specification is about serving the customer.

Testing is about isolating the problem.

Development is about solving the problem.

The process provides the framework. The process is the automated assembly line of software development.

permalink

Seven Software Development Environments

How many environments are enough?

Well one is definitely not enough. It is usually a sign of deeper problems that developers do not insist on separate environments for development and testing. One problem could be simple ignorance. In which case a few definitions are in order. So here are a typical seven.

1. Development
2. Build
3. Integration
4. QA
5. UAT
6. Staging
7. Production

They go by slightly different names from company to company but you should be able to recognize them by their function. It is also possible that several have been collapsed into one.

Development: This is the wild west. Developers get to do anything here and they will. As such anything proven here is suspect. Typically the name is shortened to "Dev".

Build: Hopefully source control is in use, if it is there is a chance automated builds or integration builds will occur on a machine that is not a development machine.

Integration : As the name suggests this is were everything comes together. A typical software solution now routinely involves multiple applications under development, a few legacy applications or libraries, some third party tools and servers. And to set it all up usually requires some configuration. This is the first enviroment were application installed. Team leads worth their salt will restrict access to this environment. Perhaps read only access will be allowed to team members but the lead should insist the problems be fixed in dev. Sometimes goes by the name "Int".

QA: Another name is "Test". Developers should have no roll in this environment. If the QA team is good they will not even let development leads have access. QA testors should be able to handle the deployment to QA without the developers. If they can't then you have bugs or lack of documentation.

UAT: The longer name is "User Acceptance Testing". Here is were the client gets a chance to provide feedback. Since QA was able to install on QA, either QA or if you are lucky enough to have a Configuration Management Team will handle this transfer. Note at this point developers are no longer needed to keep the application working.

Staging: Sometimes this go by the name "Preproduction" or PreProd. This environment is handy for reducing down time and handling security issues. It is also common for the owners of the site to refuse the developers of the site any access to this environment.

Production: Shortened to "Prod" and this is the final enviroment, the real environment.

permalink

12 Basic Software Development Practices

The gap between programming or writing code and developing software is growing.
This paradox is driven by the proliferation of easy to use tools, libraries, frameworks and OSes designed to ease the burden of software development.

Regardless of why, my experience has been that the typical software development shop is not executing on basic fundamental software development practices. A trend of late that I find even more alarming is quite often many of the programmers and managers are not even aware of or do not insist upon implementing them. It reached the point that I have enumerated 12:

12 Basic Software Development Practices

1. Source Control
2. Issue Tracking
3. Bug Tracking
4. Work Item Tracking
5. Environments
6. Integration Builds
7. Automated Builds
8. Unit Testing
9. Regression Testing
10. QA
11. Versioned Releases
12. Setups

So for a while my thinking was I can just enquire about these 12 before taking a new contract or engagement and all will be well. It is not surprising that I was always told "oh yeah we have all of that.." And it is also not surprising that expectations did not match reality. So I formulated follow on questions to determine the depth of practice.

Questions to determine depth of practice

1. Source Control

Where is the code kept?
Central location?
Individual machines?
Which version is authoritative?

2. Issue Tracking(Issues are a catch all term for everything that does not fall into the bug or work item buckets. They include but are not limited to 3rd party software issues, network issues, development machine issues.)

Is there a Central reporting tool / repository for issues?
Is there an established work flow?

3. Bug Tracking

Is there a Central reporting tool / repository for bugs?
Is there a bug workflow which includes states for:
Initial
Approved
Denied – Feature, works as designed
Denied – Not reproducible
Fixed
Verified
Reopened
Closed

4. Work Item Tracking

Is there a Central reporting tool / repository for new feature and enhancements?
Is there a work flow which includes states for:
Initial
Coded
Test
Failed
Accepted

5. Environments

Do separate environments exist for each of?
Development
Integration
Quality Assurance
User Acceptance Testing
Production

Is developer access to environments higher that Development limited?
Is developer access to environments higher than Integration denied?
Does QA or Change Management own the process of moving releases from one environment to the next?

6. Integration Builds

Does the code build from source control?
Does it build on a machine that is not a development machine?

7. Automated Builds (hourly/daily)

Is the code being built a regular basis?
Is this build done by an automated process?

8. Unit Testing

Do developers check in unit tests with their code?

9. Regression Testing

When code is built for release are all unit tests run?
Bug, Feature and QA tests?

10. QA

Is QA done by someone other than developers?
Does QA write automated or unit tests to demonstrate bugs?
Does QA write automated or unit tests to test common test cases for a feature?
Does QA write automated or unit tests for security and other required practices?

11. Versioned Releases

Is there a version number definition?
Are the products tied to the version number with each release?
Is the version number incremented with each release, both internal and external?
Does QA report bugs and test features according to version number?

12. Setups

Does each application have an install program?
If it does not have an install program are there instructions documented for manually installing the application?
After the install does the program run or is more intervention required?

Footnote. Microsoft Team System can provide them all.

permalink