Overview: Day Trading vs. Swing Trading

For anyone entering the world of stock trading, one of the first decisions to make is whether to pursue day trading or swing trading. While both strategies share the same ultimate goal — generating profit — they differ significantly in approach, time commitment, and the technical tools they rely on.

• Day traders open and close positions within a single trading session, relying heavily on intraday charts, momentum indicators, and tight risk controls.
• Swing traders hold positions over several days or weeks, using broader technical patterns and fundamental catalysts to time their entries and exits.

Choosing the right strategy depends on several personal and financial factors, including available time, account size, risk tolerance, skill level, and psychological temperament. Neither approach is universally superior — the right fit depends on the individual trader.

Splunk Inc. (SPLK): Company Snapshot

Splunk Inc. is a US-based technology company operating in the Application Software industry within the broader Technology sector. As of the trading session on Monday, June 10, 2019, the following figures were reported:

• Last closing price: $118.51
• Daily change: +6.44%
• Market capitalisation: $17.50 billion
• Earnings Per Share (EPS): -$2.11
• Shares outstanding: 147.68 million

Shares outstanding refers to all authorised, issued, and investor-held shares of a corporation. This figure equals issued shares minus treasury shares, and it includes both publicly available float and any restricted shares held by insiders or company officers.

Performance Review

Looking at SPLK’s price performance across multiple timeframes as of the report date:

The mixed performance across timeframes suggests a stock experiencing significant short-term volatility against a backdrop of modest longer-term gains. The analyst consensus recommendation for SPLK stood at 1.9 on a standard scale (where 1 = Strong Buy and 5 = Strong Sell), indicating a generally bullish outlook from the analyst community.

Technical Analysis Indicators

Volatility and Beta

Volatility measures the degree of variation in a security’s price over time. It can be expressed using standard deviation or variance relative to a benchmark index.

• Average True Range (ATR): 5.19 — indicating the average daily price range, useful for setting stop-loss levels.
• Beta: 2.05 — meaning SPLK historically moves roughly twice as much as the broader market. High beta implies higher risk and reward potential.
• Weekly volatility: 3.45%
• Monthly volatility: 3.80%

EPS Growth Projections

Earnings Per Share (EPS) is the portion of a company’s profit allocated to each outstanding common share. It is a primary indicator of financial health and profitability.

• EPS growth (coming year): 31.1%
• EPS for prior 5 years: -20.3%
• EPS forecast for next 5 years: 35.1%

While Splunk reported a negative trailing EPS of -$2.11 at the time, the forward-looking EPS growth figures suggest analyst expectations of significant improvement in profitability, consistent with a growth-stage software company investing heavily in market expansion.

Price Target

The consensus analyst price target for SPLK was set at $151.66, representing meaningful upside potential from the June 10 closing price of $118.51 — approximately a 27.9% premium.

Profitability Ratios

Profitability ratios help investors assess how efficiently a company generates earnings relative to its assets, equity, and invested capital.

• Return on Equity (ROE): 0%
• Return on Assets (ROA): 0%
• Return on Investment (ROI): -8.4%
• Relative Strength Index (RSI): 44.55

An RSI reading of 44.55 places SPLK in neutral territory — below the overbought threshold of 70 and above the oversold threshold of 30. This suggests the stock was neither showing excessive buying pressure nor distressed selling at the time of the report.

Simple Moving Averages (SMA)

Simple Moving Averages (SMAs) are widely used to identify trend direction and potential support or resistance levels. The distance of a stock’s current price from its key SMAs provides context on momentum:

The negative distances from the 20-day and 50-day SMAs indicate the stock was trading below these shorter-term averages at the time, suggesting bearish near-term momentum. However, the stock was still marginally above its 200-day SMA (+0.63%), which many long-term investors regard as a key dividing line between bull and bear phases.

Summary

As of June 10, 2019, Splunk Inc. (NASDAQ: SPLK) presented a mixed but broadly constructive technical picture. The stock showed strong short-term price action (+6.44% on the day, +8.67% weekly) despite lagging key short-term moving averages. High beta (2.05) and elevated volatility made it a candidate for active traders rather than conservative, income-focused investors. Forward EPS growth expectations and a price target well above the prevailing price reflected analyst optimism about Splunk’s long-term trajectory as an enterprise data platform.

This article is based on a historical report from June 2019. All figures are time-sensitive and should not be used for current investment decisions. Always conduct your own due diligence or consult a qualified financial adviser.

The Core Tension: Correctness vs. Change

When you start programming, the appeal is the puzzle: make the machine produce the right answer. But as software grows larger and more complex, a harder problem emerges — how do you even define what “right” means? Static typing, automated testing, property testing, and proof assistants all assume you can specify correctness up front. Most of the time in production software, you can’t.

The practical reality of software requirements is that they conflict, evolve, and are often only partially understood. Trying to resolve every corner case before writing a line of code is a path to paralysis. The better approach is to recognize that not all software is the same — and to choose your optimization target accordingly.

Sometimes correctness is possible, and it matters. The rest of the time, optimize for change, so that we can incrementally discover and approach “right.”

When Is Correctness Even Possible?

Consider how different these software contexts are: firmware baked into hardware, scientific data-reduction pipelines, financial settlement systems, internal activity dashboards, and a landing page for a 30-day ad campaign. These are not the same engineering problem. Treating them identically — insisting on full formal specification for each — is a category error.

Meir Lehman’s 1980 paper “Programs, Lifecycles, and Laws of Software Evolution” made a crucial observation: many arguments about correctness “become reconcilable or irrelevant under an adequate program classification scheme.” His classification divides programs into three types — S, P, and E — based on how well the solution is understood at the time of development.

Lehman’s S/P/E Classification

• S-programs — A solution is formally specified and derivable from that specification.
• P-programs — A problem is specified, but an optimal solution is computationally intractable; we can only seek “better.”
• E-programs — The software is entwined in the problem space it is trying to improve; requirements shift as the software is used.

S-Programs: A Solution Is Specified

An S-program is one whose function is formally defined and derivable from a specification. Given a complete, non-contradictory spec, there is a provably correct implementation. Classic examples include sorting algorithms, checksum functions, cryptographic primitives, and well-defined data-format parsers.

Writing the specification is the genuinely hard part. Committees that produce standards like CSS or the JPA specification are doing the difficult work of resolving conflicts and edge cases so that implementors can aim at a fixed target. When a discrepancy surfaces between a program and its specification, the bug is often in the spec itself.

Once an S-program correctly implements its specification, it is effectively done. You might tune it for performance, but the specification hasn’t changed. If the requirements change, you have a different S-program — possibly one that borrows code from the original, but conceptually separate. S-programs are the puzzles we can fully solve, and solving them is deeply satisfying.

P-Programs: A Problem Is Specified

Some problems can be precisely stated but not optimally solved in tractable time. The classic example is the travelling salesman problem: we can define the objective function exactly, but finding a globally optimal route over large graphs is computationally prohibitive. We can find better and better approximations, but not a provably perfect answer.

Statistical simulations such as Monte Carlo methods also belong here. They cannot be exhaustively tested because they are not deterministic by design. Mathematical reasoning and formal proofs carry more weight than test suites in this domain.

Lehman notes that P-programs evolve as we learn more about the problem — new constraints surface once an algorithm is in use — which is why he groups them with E-programs for lifecycle purposes.

E-Programs: Software Entwined in the Problem Space

Everything else — and this is the vast majority of custom software — falls into the E category. These are systems built with incomplete requirements, deployed into environments that change, used by humans whose needs and behaviours shift in response to the software itself.

Lehman called these programs “embedded” (meaning embedded in a sociotechnical system, not embedded in hardware — a terminology choice that causes confusion). A better word is entwined. The program becomes a part of the world it models. Deploying new software changes the human system around it, which generates new demands on the software. As Lehman wrote: “The need for continuing change is intrinsic to the nature of computer usage.”

E-programs are never truly “done.” If your goal is to close tickets and ship finished things, this can feel unsatisfying. If your goal is to help real people with real problems, E-programs are where the most meaningful work happens.

Compose Applications from S-Programs Wherever Possible

Lehman’s insight that applications should be built from well-defined, correct S-program components is sound. His mistake was in the sequencing: he believed you should fully decompose the application into S-programs before writing it. In practice the order is reversed. You build the fuzzy, evolving E-program first, and S-program components emerge from that process over time as understanding solidifies.

Lehman also assumed each S-program component would be implemented by the development team. The modern reality is different: you search for existing, already-verified implementations — open-source libraries, frameworks, SaaS components — and adapt the application design to use them. Custom software development today is far more about integration than original construction.

S-Programs Are Reusable: Optimize for Correctness

Because S-programs are well-specified, they are reusable across projects. This property — and the intellectual satisfaction of solving a clean puzzle — is what drives the enormous ecosystem of open-source libraries, language standard libraries, and software-as-a-service primitives.

A practical signal that you have found an S-problem inside a larger E-program: the sub-problem feels abstract and general, and a nagging sense surfaces that someone has already solved it. That is usually correct. Search before implementing.

When you are creating a reusable S-program, correctness is the right optimization target. Use property-based testing, type systems, and formal reasoning where practical. This investment pays back every time the component is reused.

Problems Migrate from E to S as Understanding Matures

The boundary between E and S is not fixed. Components that start out as bespoke, imprecisely-understood parts of an application can later be extracted, generalized, and turned into well-specified, reusable S-programs — but only after the problem has been solved enough times in enough contexts to be fully understood.

Object-relational mapping is a good historical example. Development teams wrote custom ORM code inside their own applications for years. Once the problem was widespread and well-understood, frameworks like Hibernate could solve it broadly. After that, a standards committee could write the JPA specification — a formal S-program target. Similarly, CRUD application patterns became clear enough through repetition that a framework like Ruby on Rails could encode them as reusable conventions.

Good standards emerge from many implementations; correct implementations then follow from good standards.

E-Programs Are Most Custom Software: Optimize for Change

If you are building software for humans to use inside a business context, you are almost certainly building an E-program. It is fit for a specific purpose, part of specific operations, and not designed for reuse outside that context. The job is not to make it permanently correct — it is to make it correct enough now and keep making it better. The optimization target is change, not correctness.

What does optimizing for change mean in practice?

Don’t Write Code — Change Code

Lehman analysed the traditional software lifecycle — Requirements → Design → Detailed Design → Programming → Test → Rollout → Maintenance — and noticed that problems clustered at the handoffs between phases. He also noticed that every earlier phase appears, in miniature, inside Maintenance. His recommended fix was to strengthen the separations between phases. The better answer, now visible with hindsight, is to collapse them: start somewhere and iterate. Make every change small and safe. When changes are small enough, the phases blur together and the handoff problems disappear.

Practically, this means:

• Establish a walking skeleton of the application early, before it does anything useful.
• Wire in continuous integration and automated testing from day one, not as an afterthought.
• Automate deployment so that shipping a small change has a low and predictable cost.
• Treat security scanning and quality gates as part of the delivery pipeline, not a separate phase.

These are not optional polish. They are the table stakes for playing the “change software safely” game.

Reduce the Fear of Changing Code

The biggest obstacle to continuous change is not the effort involved — it is fear. Fear that a change will break something, that a refactoring will introduce a regression, that a deployment will cause an outage. Modern engineering practices directly address this:

• Refactoring with automated tests lets you reshape code with confidence that behaviour is preserved.
• Microservices and module boundaries limit the blast radius of any single change.
• Infrastructure as code and deployment automation make the operational side of change repeatable and auditable.
• Feature flags decouple deployment from release, so you can ship code without exposing it to all users at once.

Lehman even anticipated service-oriented decomposition in 1980, noting that each module could run on its own processor in a distributed system — while acknowledging that many problems with such architectures remained unsolved. Many of those problems now have established solutions.

Change How You Change Code

The most important architectural question for an E-program is not “what should it do?” but “how will we change it?” Good architecture defines both a target state and a practical path from here to there.

Your delivery pipeline is itself an E-program. The software you need to deliver changes. The infrastructure you deploy to evolves. The quality checks your organisation requires shift over time. Treat your CI/CD configuration with the same care you give production code: version it, test it, and refactor it. A rigid pipeline becomes a bottleneck as fast as rigid application code.

When You Can’t Know “Correct,” Aim for “Better”

Lehman wrote: “Absolute correctness of the program as a whole is not the real issue. It is the usability of the program and the relevance of its output in a changing world that must be the main concern.”

Usability and relevance are not easy to unit test. But they can be measured. Instrument your features to detect whether users actually engage with them. Observe the effect of a change on the system the software is entwined in. Use that signal to decide whether the next change should reinforce, revise, or reverse what you just shipped. A feature that nobody uses is not correct in any meaningful sense, regardless of how many tests it passes.

Summary: Choosing Your Optimization Target

Recognize which type of software you are building. Reach for existing, correct S-program components wherever the problem is well-understood. Build the entwined, human-facing parts of your system to change safely and often. Measure outcomes in the real world, not just in test suites. That is how you make software that is genuinely useful — not just technically correct.

By now, most people in IT and product management understand DevOps. The power of DevOps, like Agile, is that there’s no strict rule set to follow, nor is there a standard to adhere to. It’s open to interpretation and adaptation according to your own corporate, customer, product, or cultural situation.

However, corporate culture sits square in the cross hairs of what DevOps aims to improve. With this in mind, is it better to change corporate culture at the time you adopt a DevOps practice, or wait for your DevOps practice to influence cultural change organically over time? As usual, the answer is: it depends. But here are some suggestions for a smooth transition.

Who does DevOps affect?

Typically, DevOps is cited as helping unite and influence the culture and work processes of an organization’s:

• Software developers – those tasked with creating and modifying software
• IT operations personnel – those tasked with keeping systems available
• Quality assurance (QA) staff – those tasked with finding issues before users do

One goal is to remove barriers and silos that derive from IT’s role to keep things stable, developers’ role to disrupt (through new features), and QA’s role to uncover issues early and avoid risk. These obtuse goals can put people in these groups in adversarial positions (i.e. developers taking QA’s bug findings personally, and IT blaming developers for issues in the environments they’re responsible for). Therefore, it’s important to ensure everyone learns to work together towards the same end-goals: customer satisfaction and business growth.

Expanding the culture of DevOps

However, the three groups above aren’t the only ones your DevOps practice should focus on. Arguably, it’s just as important to include your customer support staff, product management, and even executives in your DevOps practice.

The biggest reason to include support staff is so that there are no surprises when new or modified features (even removed features) are released. I’ve heard horror stories of support staff getting customer calls on a Monday because of changes that occurred over the weekend, which they had no idea was even planned. When your own staff hears about application changes from your customers first, you should improve your culture of communication as soon as possible.

As for executives, there’s immense value in understanding the hidden business impact of top-down decisions. DevOps can also help influence future executive business direction based on feedback loops from within the organization as well as actual software users and customers. A culture where executives are disconnected from what happens on the front lines hurts morale, customer satisfaction, and ultimately the business.

The DevOps turnstile: Continuous cultural improvement

Let’s look at some specific cultural changes you should enact ahead of time or expect over time with a DevOps practice. However, regardless of whether a specific cultural change is listed as either “before” or “after” DevOps is implemented, all of them should be considered subject to continuous improvement. For example, team building to instill trust isn’t something that’s done just once; it’s a continuous process. Let’s begin with some changes to enact when you begin your DevOps journey:

Exposure to real user feedback: It’s amazing how many organizations never hear from or know who their users are. I’ve experienced this multiple times myself. Understanding firsthand that the product they support has positive impact on real people can go a long way towards improving motivation. There’s no need to wait on this one; encourage communication with users right away.

Team building: As stated previously, this helps instill trust between teams, avoids finger pointing, and helps to align individual motivation. Teams that connect on a personal level tend to work more as a unit. This culture of cooperation will strengthen as everyone sees the benefits.

Create channels of collaboration: This goes beyond installing instant messaging or other real-time collaboration tools. It starts with team building and continues with cross-functional team meetings, and the encouragement of unofficial meetings and gatherings. Instead of working to silence disagreements or frustrations, help teams constructively voice their concerns or criticisms. Proper coaching can help teams grow stronger together even when they disagree at times, have differences of opinion, or get frustrated with one another.

Sharing roles: Have developers take part in IT staff procedures, such as software deployment and system monitoring. Additionally, include IT in software development sprint planning to provide feedback into software design and feature development. After all, both groups have valuable insight into system behavior, but from different points of view. The cross pollination eliminates bottlenecks, and helps people feel more valuable to the overall process.

The following cultural changes are best influenced over time, aftera DevOps practice is in place:

Design for testability: Including QA in sprints helps to build software for testability—even though the main goal is to meet customer needs—because a system that’s testable tends to be of higher quality. In fact, I once worked in a group that required a test plan along with each story. After all, if you don’t know how you’re going to test a new feature, how do you know you’re building it right? This culture of QA goes a long way towards increasing customer satisfaction through quality.

Create a culture of autonomy and mastery: In this change , each contributor has fewer dependencies on others to achieve personal and organizational success. In turn, each team member feels empowered to make a bigger difference. This is definitely a cultural change that takes time to develop and refine, especially since it varies by individual. The rewards are many, for both the team members and the organization, as this approach builds both confidence and velocity.

Reduced fear of failure: This is another cultural change that will take time in most organizations, and it’s best to build confidence in your DevOps practices before expecting everyone to feel comfortable with failure. Of course, failure is never the actual goal. However, in a true lean, agile organization, failure is encouraged early in order to make corrections sooner rather than later.

Encourage knowledge and skill sharing: It takes time to expect people to grow comfortable enough to share their knowledge and skills, and in effect level the playing field by losing what they feel makes them uniquely valuable. However, as a successful DevOps practice eliminates bottlenecks, no one will want to be identified as a bottleneck themselves due to lack of transparency. As team members witness first-hand the benefits of sharing and transparency, they’ll open up more and more, making themselves more valuable in the process.

Continuous maturity

As your organization matures along with its DevOps practice, you should see positive cultural improvements as a natural offshoot; it’s best not to force it. And although the goal is to better serve your users while growing the business, there’s no reason not to enjoy the process while doing it.