LOGIN
START FREE TRIAL

LogSense Blog

See everything, even before it happens.

8 Myths about Application Development

Aug 12, 2019 11:43:40 PM |     Przemek Maciołek, PhD
img-8-myth-blog

The cloud era has changed the art of software development in many ways. Some things that used to be true aren't anymore, and vice versa. Many truths endure, even if people think they're no longer relevant.

Myths have grown out of both change and resistance to change. Sifting through fact versus fiction can be a real challenge, especially when you're trying to create something meaningful, as quickly and efficiently as possible. Let's look at eight common myths that developers face in their application development cycles.

1. Agile means that planning and design are obsolete.
Developers can't turn around without hearing about agile application development. Some people treat "agile" as a buzzword that justifies any sloppiness as long as you have sprints and scrums. However, sloppiness has no place in a successful application development run. The agile development philosophy recognizes that designs can't be set in stone as the project moves forward. It also acknowledges that no complex project can succeed without a clear plan and one that promotes flexibility. The details might change in response to testing and user feedback, and the design needs to accommodate change. A good plan leaves room for the unexpected.

2. Security and scaling are afterthoughts.
One of the most significant changes in modern application development is the need for scalability. A proof of concept that works with one user will serve a thousand only if scalability is part of the design from the beginning. Resource management is a major consideration in modern software where user experience is critical to the application's success. Security is essential to any software that faces the Internet. Developers need to use secure practices from the start, rather than thinking about how to make the code safe after deployment. Performance and security increasingly are moving to the left as part of the developer's responsibilities.

3. Improving performance is next to impossible.
Developers who typically write single-threaded code may believe it's impossible to get good performance out of massively distributed systems. If the code is weak on observability, discovering and fixing performance bottlenecks certainly will be difficult. Developers need to learn the techniques that allow measurement of performance and identification of problems. They need to work together with analysts to make their code friendly toward analytic tools. There are tools (like LogSense) that help developers use the information available in traces and logs to boost performance and enhance the overall user experience.

4. Logs are useless.
Logs may seem useless when there's such an overwhelming amount of data included in them. Working with logs often becomes an exercise in frustration. They contain so much data, only a fraction of which constitutes useful information (without a ton of manual work). Nearly every system has its own log. Each log has its own format. How can you manage to make sense of the information, especially when some tools require you to write a bunch of custom code? Developers need to become systematic about logging techniques, and they need to look for tools that can remove some of the burdens. Automated pattern discovery is a modern technique that transforms unstructured data into structured. Once structured, developers can create charts or graphs more easily to tell a story about what's happening in their application development cycle. Better observability can improve application development.

5. Adding more people makes the schedule shorter.
If one is good, then two is better, right? Not necessarily. Likewise, adding people to a project late likely will make it late still. It may be possible to rescue a late project by adding resources if the goals of those specific additions are concrete. But sometimes the answer might have to be cutting back on the goals for the first release. Better tools may help, or you may need to fix problems in the development process. Sometimes you have to accept that the release will take longer than expected and figure out how to deal with that on the next release.

6. When the software is released, the developer's job is done.
There's no such thing as perfect software. Any application that's complex enough to do something interesting has bugs and inefficiencies. The finished product won't always match the ideal for the user. Even if the software was created under a contract and signed off, sooner or later something will happen. There may be urgent problems that open a security hole, cause crashes, or deliver incorrect results. These issues need prompt fixing. Or, perhaps user requests for new capabilities or for functionality that could work better will accumulate, requiring a new release with additional features. There's always room for improvement and innovation. The developer's job is never done. And that's what makes development work interesting.

7. Testing starts only after the code is written.
This type of thinking is a remnant of "waterfall" thinking, where the code is designed, written, and tested in non-overlapping stages. Testing should happen alongside writing code, not as an afterthought. Testers should get their hands on the code as soon as there is some functionality to test. Build, test, fix, repeat. Letting others see early code may embarrass some developers, but it's part of the job. Delaying testing makes problems harder to find and fix. Great developers understand and embrace this process.

8. Testing means just finding bugs.
Software testing does include finding bugs, but that's only the beginning. Performance concerns (or enhancements) are a big piece of the testing. If testers encounter serious delays or erratic response times, they should file reports on those issues. Sometimes a task inherently takes a long time, but often the delay is the result of code that needs improvement. Testers should report cases where the user interface is clumsy or unintuitive. Again, user experience is everything. The point is to deliver software that doesn't just work "correctly" but offers an incredible user experience.


Recognizing and avoiding these myths makes development teams more productive. Developers and testers work together better and waste less time. If you're interested in learning more about how LogSense can improve your application development cycles, get in touch or set up a free trial today!

 

New call-to-action

 

 

Topics: appdev

Want more of the LogSense Blog? You got it.
Subscribe to our newsletter.

Comments