There is general consensus that the software development process is imperfect, sometimes grossly so, for any number of human (management, skill, communication, clarity, etc) and technological (tooling, support, documentation, reliability, etc) reasons. And yet, when it comes to talking about software development, we apply a variety of scientific/formal terms:
- Almost every college / university has a Computer Science curriculum.
- We use terms like “software engineer” on our resumes.
- We use the term “art” (as in “art of software development”) to acknowledge the creative/creation process (the first volume of Donald Knuth’s The Art of Computer Programming was published in 1968)
- There is even a “Manifesto for Software Craftsmanship” created in 2009 (the “Further Reading” link is a lot more interesting than the Manifesto itself.)
The literature on software development is full of phrases that talk about methodologies, giving the ignorant masses, newbie programmers, managers, and even senior developers the warm fuzzy illusion that there is some repeatable process to software development that warrants words like “science” and “engineer.” Those who recognize the loosey-goosey quality of those methodologies probably feel more comfortable describing the software development process as an “art” or a “craft”, possibly bordering on “witchcraft.”
Read the whole article on the Code Project.
Individuals and interactions and processes and tools
Working software and comprehensive documentation
Customer collaboration and contract negotiation
Responding to change and following a plan
In direct contrast to the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Why? Because the Agile Manifesto creates tension between frequently opposing forces, leading to imbalance and extremes, which is one of the reasons Agile Development fails in actual implementation. Conversely, I prefer to find the appropriate balance between the two, as appropriate for the client and the task at hand.
That’s the test rack.
At home, I have a smaller configuration:
That thing in the old DVD player box is the test fixture I’ve been using (I did not build that!)
What you’re looking at there is:
- a 24 port switch
- a PoE switch
- 5 beaglebones (4 Greens, one Black)
- the black box on pull out table the left is a wireless hub, unrelated.
- a small box on the right on top of the 24 port switch is a VOIP box, also unrelated.
In your open letter to the EU, you wrote:
At the time, Cork was suffering from high unemployment and extremely low economic investment. But Apple’s leaders saw a community rich with talent, and one they believed could accommodate growth if the company was fortunate enough to succeed.
We have operated continuously in Cork ever since, even through periods of uncertainty about our own business, and today we employ nearly 6,000 people across Ireland.
We received guidance from Irish tax authorities on how to comply correctly with Irish tax law.
There are a lot of communities in the US rich with talent.
Those could be 6000 Americans across the US.
That $14.5 billion in taxes should have been paid to the US government to benefit Americans.
But instead, you hide the simple fact that your smart lawyers found a tax loophole, and that’s the only motivation for hiding in Ireland. Because the reality is:
“Member states cannot give tax benefits to selected companies – this is illegal under EU state aid rules,” said Commissioner Margrethe Vestager.
“The Commission’s investigation concluded that Ireland granted illegal tax benefits to Apple, which enabled it to pay substantially less tax than other businesses over many years,” she added.
The standard rate of Irish corporate tax is 12.5%. The Commissions’s investigation concluded that Apple had effectively paid 1% tax on its European profits in 2003 and about 0.005% in 2014. (source)
So stop trying to pull the wool over our eyes, because I for one am not buying it, or your products.
I posted a new article about high level QA concepts posted on the Code Project here.
Working with QA can often be an adversarial situation, but in reality, it shouldn’t be. The developer, customer, marketing, CTO, CEO, accounting department, and so forth, are all stake holders in delivering a functional, aesthetic, secure, safe, and easy to use product. This article can only scrape the surface of what those six terms:
- easy to use
actually mean. Depending on the product being developed, they will be weighted differently as well. Security may be paramount in a server handling REST requests, where aesthetics is irrelevant because there’s no customer facing UI. Safety may be the priority in a piece of medical equipment or an engine cut off switch on an airplane. Safety may be irrelevant in a mobile game application (unless you want to make sure the person isn’t crossing a street or driving while playing the game.) So, depending on the application, you may be addressing some or all of the above concerns, and the QA process should provide the right balance of coverage based on how those (and things I’ve omitted) are tested.
Ultimately, the QA process is like a mathematical proof – it consists are formal, repeatable processes that validate and verify the application.
I rarely (probably never) just post a link to something else. But Robert C. Martin’s “The Churn” is an absolute must read for all those newbie wannabee waltzing in hackoders that think they’re hot shit with their latest techie-tech. And is a must read for all those project managers sucked into the event horizon of the bling-hole.
“We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes. And become a goddam profession.”