In this post I’ll show how well formed outcome and decomposition play together in the software development.

As I’ve said before, the most important factor in the software development goals is being specific. As far as it is achieved, the simple and recursive process is applied.

First of all, when Customer comes with a Product idea, we make it specific by specifying business goals and context. Since any non-trivial Product is, well, non-trivial (otherwise why we, Developers, would be necessary?) we have to decompose it.

Thanks to 40 year history of software development industry, we don’t have to invent it. Just use the accumulated knowledge wealth. We decompose business requirements to the software requirements, consisting of

• architecture
• users
• data model
• user-level functions or use-cases
• user interface (screens description if the Product to be GUI or web)
• description of how it should integrate with other software and hardware (including OS, DB and web server, as necessary)
• security and confidentiality requirements
• license requirements, stating how the Product would be licensed by the Customer and, therefore, what third-party components are compatible with the target license
• other requirements, as necessary

and make each of them a well-formed goal.

Since almost all software projects are non-trivial - that is they don’t fit entirely into a single developer’s head - we have to decompose further.

Projects are about functionality, usually. When they’re about data, we call them database engineering. When they’re about user interface, we call them (user interface) design. Neither of two are the topics of this article, so we focus on functions.

Non-trivial (see above for the definition) software functionality is again too complex to implement it straight ahead and we decompose again. Each function in the function list turns into the detailed function description:

• short nickname
• goal and description
• invocation method (click, REST HTTP call, function call, unix shell, etc)
• event flow
• tests - to fulfill the “being specific” criteria of the well formed outcome
• tickets - how we split the function development into work chunks.

Each test set should test every possible category of a wrong input and have at least one example of a correct input.

Usually we split the function into two or more tickets. When function is complex or tests are non-trivial, we assign a ticket to each test.

Here (and only here) one may start the development: the functionality is already well formed, the Developer had agreed with the Customer what consists the correct function implementation (use tests, Luke!).

But here lies a potential showstopper. In any non-trivial project (we don’t do trivial ones, right?) the interdependencies between internal parts are quite complex, so they don’t fit a developers head entirely. Therefore, ideally, all tests are to be executed after each change to the software code.

Doing tests manually quickly turns into a nightmare: make a 5-minute change and run 5-hour tests. Gladly, we have a computer to offload the testing to.

Yes, here we get automated tests. Straight out of a well formed outcome be specific criteria!

Even more, we shouldn’t bother from this moment with thinking out our software too wide. Please, get me correctly, I’m not saing you don’t have to think about, do design it at all. I mean that you can focus now exactly on the next test that has to be implemented. And, to ease it further, we may implement tests first and then just hit make test (bond to F9 in my emacs) to see what’s wrong with our implementation and where we should head.

Yes, the distance from automated tests to a test-first development is very short.

Bonuses you get:

• recover a work focus instantly, doesn’t matter if you switched out of the project five minutes or five years ago or you haven’t worked on it at all
• (manager’s bonus as a conclusion of the above) easier staffing
• your software has now a tests skeleton that doesn’t depend on your implementation
• (developer’s bonus as a conclusion of the above) easy refactoring
• instant delivery: you need just to check out the last version that passed all the tests and ship it

.. and so on, and so on.

So, the above shows how two simple principles of well formed outcome and decomposition lead to the test-first development.

Note that we only scratched the surface of the agility. With the test-first, you easily may implement any rational software development process, from the waterfall to the one-day-iteration XP. The only thing you won’t be able is being chaotic again.

Also note that a surrending to the frequent intent to implement tests after the code, you start playing completely different game of adjusting your goal to your results. Like in soccer, insead of heading the ball to the gate, you put the gate where your ball is.(thanks to Yuri Rashkovskii for usefull analogy)

More recent links about tests, test-driven development and how it can go wrong:

• Useful test criteria
• Ideal test qualities
• More about layered testing strategy
• How test driven development can go wrong
• Python dependency injection test method.

1 Comment »

Does Bad Writing Reflect Poor Programming Skills?

Writing is a communication skill. And they say that communication skills and the other soft skills are what programmers need today. Effective developers don’t work alone. They work with others in a team. And a team member needs to communicate with the other team members to be effective.

[…]

Writing good prose, and good code, is more about style than about substance. Yes, the substance, the message is also important. But if your style is cluttered and unfocused, no one will grok your message. Your substance won’t matter.

Timothy King gives a deadly good example on communicating with code and comes up with three tips, I’m after:

1. Understand the material before you write.
2. Write as though your audience is a fourth grader.
3. Think about how readers might misinterpret you.

These apply both to documentation, code and chat, as I might say. Even using them I use to restate things several times until my listener catches the idea, so I’d add this too

4. Say the same thing several times in different ways, so at least one of them would be successful.

No Comments »

You Scaled Your What?

“We’re embarking on a project to provide us 4X improvement in scalability.”, said the enthusiastic architect.

“Really, in what way?”, I replied, knowing that the trap had already been laid.

“What do you mean, it’s obvious, we will have 4X the scalability of our current architecture when we’re done!”, my com-padre stated with a confused brow.

“Is that transactional headroom, storage improvements, reduction in operations staff, or time to market for new features?”, I offer, struggling to hold back a wry smile.

“Uh, well, I guess it’s transactional headroom, or at least that is what I call scalability.”, he offers, realizing this is probably not going where he wanted.

“Well, can you achieve your 4X scalability if you experience a 4X increase in data volume?”, realizing that I now feel sorry for him.

Yes, this conversation happens far too often. Scaling systems actually require managing the scaling along all of the vectors. Ignore one and that will be the one that becomes your next bottleneck. But what are the vectors? Where is our friend, full of enthusiasm, misguided? Let’s look at the minimal set of scalability vectors that should be considered in every architecture.

The article reviews distinct properties of scalability of an IT business architecture. Dan outlines the following traits:

• Transactional scalability
• Data scalability
• Operational scalability
• Deployability
• Productivity
• Feature time-to-market

He sums this up with a nice spider diagram with an unreadable font, providing visual mapping of those concepts.

No Comments »

This is second article about software development basics.

The first one was “Software development basics: well formed outcome”.

This tool, in contrast to the Well Formed Outcome, is very well known by software developers.

Divide and conquer - what can be simpler?

– How an elephant could be ate?
– Sliced.

Enough said. Will conclude with two wikipedia links: Decomposition and Decomposition paradigm. They distinguish between object-oriented and structural program decomposition, but this really doesn’t matter. The instrument stays the same.

The next article will cover the specifics of implementation of a Well Formed Outcome and Decomposition in the software development.

Update. The other term for the Decomposition is the Separation of Concerns

3 Comments »

Paul’s Pontifications » Blog Archive » New Software Technology: Blockage On Line

Every company has a few eccentric engineers who try to explain why this or that new technology would be a great investment. Sometimes they are even right. But they are almost never taken seriously. And so great technologies that could actually save the world a great deal of money on software development (not to mention improve quality a lot as well) languish on the shelf.

Paul makes great deal on explaining why most of developers still err.. develop in languages, who borrow their expression power from sixties. Yes, I mean C and C++, Pascal (which is still alive with Delphi project requests) and, yes, Java.

That’s why we get a stare so frequently when propose to develop in python, not to mention less mainstream development. Well, Ruby-on-Rails was successful lately in getting a name. But that’s just a single name.

So, is there a way for offshore software development company to increase its productivity by not developing another webproduct in J2EE/ Struts/ Oracle/ whateverbuzzwordyouwannaputhere?

Strategically, there are only two ways for such company to succeed:

1. Have good sales, deliver the promised on time and within budget, lower costs. Lower risk, lower margins.
2. Have a good product. Huge risk, huge margins (remember Skype?)

In the both cases, the company has to reflect the needs of its customers. But the instruments choice in the first case is too frequently done by customers, not by developers.

Where to find such sound customers? Read the Paul’s post.

The only viable solution for a management structure to check a new technology is to form a startup. Internally or forming a completely different company - it doesn’t matter.

So, if you’d like to develop non-mainstream for somebody else, seek such people. Seek startups. Get known in the non-mainstream community of your choice and listen carefully.

You decided to go another route - to develop a product? My congratulations, you’re risky person. You’ll be rewarded. Sometime later. Perhaps. Somehow. So, just don’t put all eggs into one basket, or you’ll lose too much.

No Comments »

With 40 years of history of the software development industry, it’s a pity that many developers still do not understand the real basics, the psycological background under the software development.

One may make sure that this is true not only by looking on real life stats of software projects (half of projects are either canceled or out-of-bonds), but talking to their roommates, colleagues, CS students.

I do a software development course and only half of my students during first setup lecture gives the correct answer on

What you would start your software project with?

Even with simplest model of software development project: Single Customer, Single Developer…

Ok, my students are not brightest MIT or CalTech guys, but one half?..

A software project is a project. Per wikipedia and PMI definition that means that:

• it has a start
• it has an end and
• it is aimed to creation of something

In other words, each and every software project has a goal.

So why not use a psycological wisdom, that’s public and available for ages, to assist ourselves in that goal achievement process?

In the psycology of an individual, the goal achievement is one of most developed areas. As the matter of fact, our life is a goal achievement process that consists of reaching goals of the smaller scale.

Since there is a quite notable distiction between reaching a goal and a failure to reach it, if I’m interested to make it, I may wonder:

• What are necessary components of a reacheable goal?

Well, it is easy! It is not a rocket science, just google for “well formed goal“. At time of writing this, google gives the “Well formed outcome” wikipedia article as the third result.

The basic criteria of well-formed outcome are:

1. Positiveness. That means that any project aimed at, say, “prohibiting spam and viruses from my desktop” is dead from the beginning. You simply can’t make negative. Just try to make a negative proof that you don’t drink congac at mornings.
2. Be specific. The most important trait for the software development goals. Know what you’ll see, hear, feel when you’ll reach the goal. Be as specific as you can. And even more. Use all sensory systems to define your goal. Being not specific enough is the first cause of goal failure.
3. Be possible and achievable. One may argue that almost anything is achievable. In practice, this means that you, who strives to reach the goal, think that it is possible right here and now. Also see the next condition:
4. Have all the resources. Have a PC; have an Internet connection; have a power, both electrical and personal to do a project; have a knowledge and skills necessary; have good communications with a Customer, et cetera, et cetera. Nearly everything might be a resource (including this checklist), which you may have or may have not. To my experience, not having enought resources is the second most frequent cause of a failure to reach a goal.
5. Have well-defined time frame. No, Mr. Customer, be ready by yesterday is not a well-defined time frame.
6. Be ecological. You, who work on reaching the outcome, please know what it takes and what it leads to. Yes, making a million via robbing a bank might be a well-defined goal. But only if you accept the cost and the consequences of such behaviour. Me - not.

The machinery behind the well-formedness is just the Nature. Human brain, from the cortex till the spine is aimed at reaching goals. The whole evolution from bacteria to trillobyte to homo sapiens is a history of reachin goals. If somebody missed a goal - he was soon to be a dead meat. So literaly every human (I don’t know non-human software developers, if you know - please, let me know) has an exceptionally powerful goal reaching mechanism inside.

To me, a software development project is a translation endeavour. A Developer translates Customer’s ideas into machine language. The criteria set out above are just an instruction for translation of vague intentions to a something that our subconsious understands and trained to do.

Why not make the first real step necessary to reach the goal - define it well?

4 Comments »

On “Rigid Agile?“:

Mishkin Berteig from Agile Advice follows up and tries to explain. The hypothetical situation is Sarah. Sarah’s bosses want her to work on a different project for a day, to add a feature that would give them a sale. To me, this is a simple cost/benefit analysis. Is the feature (and resulting sale) worth losing a day of Sarah’s work on her current project? If so, get the stakeholders to remove one day of work from the current iteration to compensate. Problem solved. […]As an exercise, re-read the two articles, and all the pronouncements about how Sarah spending a day on another project would “stop the whole team” (Berteig’s words), cause the whole iteration to be reset and seriously damage both the business’s trust in the development team and Sarah’s self-worth. Now imagine she instead had to take the day off to care for her sick three-year old son.

I’d better agree with the AgileAdvice analysis. And it will be so until someone will be successful in bringing together:

• a sales or a Customer that want’s “just two hour” feature to “be online yesterday”
• the current project Customer
• developers.

Until that no solution that satisfies everybody is even possible. Question #1: how frequently you have this? Me - quite seldom. And even the possibility such solution doesn’t guarantees that it would be found. Even if that sales and the current project Customer is the same person I won’t bet it would be. Believe me, I have such customer.

The reason behind this is that any customer (including the customer paying you money now) tends to interpred any words said (and even not said) by you as your commitment. Even if it was stated in triplicate in 24pt bold that the said is just a preliminary estimate.

And, be sure, anyone asking if you can squeeze in an “urgen tiny two-hour feature”, he expects that all your previous commitments will hold. Even if he says the opposite! (Is there anyone who expects him to say his boss/customer that he by his own delayed the project? Ha! There always developers to point to!) So, the only clean solution, if the situation above happens at the beginning of the iteration is to trash the iteration plan to /dev/null and replan the iteration. Canceling every iteration commitment made and reestablishing new ones.

Or to say that nothing during this iteration is guaranteed. If anyone thinks there’s a different solution, I have a wonderful tiny project “with fixed requirements”! And Brookling Bridge accompanying it.

Ah yeah!.. People get sick… Yes, people go vacation, get sick, and get hit by the bus. But what’s new to the Agile?

Have a good development!

1 Comment »